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ABSTRACT 


Current  network  administrators  use  network  management  software  to  monitor  and 
eontrol  elements  within  a  network.  This  is  largely  a  manual  proeess  since  managers  must 
interrogate  devices  individually  and  evaluate  performance  statistics  manually!.  The 
systems  provide  multiple  views  on  network  data  but  lack  capabilities  that  allow  operators 
to  visualize  network  performance.  Since  personnel  are  required  to  identify  problems, 
interpret  potential  solutions,  and  decide  on  appropriate  corrective  measures  without 
automatic  assistance,  maintaining  and  solving  problems  for  a  network  can  be  time- 
consuming  and  complex  significantly  reducing  network  efficiency. 

Since  FORCEnet  is  a  heterogeneous  concept  that  combines  various  C4I  networks, 
sensors,  weapon  systems,  and  platforms,  a  new  model  must  be  developed  for  network 
operations.  This  paper  researches  an  improved  model  for  fleet  network  operations 
management  for  distributed  sea-based  forces  using  existing  technologies.  Combining 
collaborative  tools,  a  Decision  Support  System  (DSS),  and  Augmented  Reality  (AR) 
imagery  transforms  Navy  information  network  management  from  a  “minimum  threshold” 
to  an  “operations  fusion”  perspective.  Little  is  known  about  AR  technologies,  but  the 
potential  exists  for  virtual  network  operations  centers  that  can  remotely  direct  networks 
for  sea  and  shore  assets  through  collaborative  efforts.  The  DSS  provides  models  for 
optimization  and  a  knowledge  base  of  potential  actions  (corrective  and  preventative).  The 
product  of  this  paper  will  serve  as  a  baseline  for  network  operations  in  the  network 
centric  environment.  Further  research  would  support  the  development  of  heterogeneous 
virtual  command  and  control  environments. 


1  Computer  Network  and  Internets,  pp.  562-563,  Douglas  E.  Comer.  Prentiee  Hall  Publishing. 
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I.  INTRODUCTION 


A.  BACKGROUND  AND  PURPOSE 

The  Navy  recognizes  that  information  can  dramatically  increase  combat 
effectiveness.  Developed  by  the  Chief  of  Naval  Operations  Strategic  Studies  Group, 
FORCEnet  emerged  as  the  enabler  of  the  strategic  concept,  SEAPOWER  212.  EORCEnet 
seeks  to  provide  “superior  knowledge,  leading  to  increased  combat  power”  through 
“integrated  sensors,  analysis  tools,  and  decision  aids. ”3  This  concept  will  have  far 
reaching  effects  on  core  and  peripheral  processes  within  the  Navy.  Since  EORCEnet  will 
have  such  an  important  role,  it  is  essential  that  it  is  carefully  implemented. 

This  research  seeks  to  support  the  EORCEnet  initiative  by  providing  a 
transformed  model  for  fleet  network  operations.  An  important  distinction  must  be  made 
because  the  goal  of  this  research  is  not  to  describe  the  implementation  of  EORCEnet. 
This  research  will  address  a  core  function  that  will  apply  regardless  of  how  EORCEnet  is 
implemented.  It  will  establish  a  baseline  for  the  fleet  network  operations  centers  that 
provide  critical  services  related  to  information  system  management.  Network  operations 
are  important  because  it  is  an  underlying  function  required  to  effectively  operate  the 
various  networks,  sensors,  devices,  and  information  systems  that  will  be  used  in  the  fleet. 

Current  network  administrators  use  network  management  software  to  monitor  and 
control  elements  within  a  network.  This  is  largely  a  manual  process  since  managers  must 
interrogate  devices  individually  and  evaluate  performance  statistics  manually4.  The 
systems  provide  multiple  views  on  network  data  but  lack  capabilities  that  allow  operators 
to  visualize  network  performance.  Since  personnel  are  required  to  identify  problems, 
interpret  potential  solutions,  and  decide  on  appropriate  corrective  measures  without 
automatic  assistance,  maintaining  and  solving  problems  for  a  network  can  be  time- 
consuming  and  complex  significantly  reducing  network  efficiency. 


2  http://www.usni. org/Proceedings/Articles03/PROmayo02.htm#defiiiing,  Feb  04 

3  http://www.usni.Org/Proceedings/Articles03/PROmayo02.htm#defining,  Feb  04 

4  Computer  Network  and  Internets,  pp.  562-563,  Douglas  E.  Comer.  Prentice  Hall  Publishing.  2001 
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Since  FORCENET  is  a  heterogeneous  concept  that  eombines  various  C4I 
networks,  sensors,  weapon  systems,  and  platforms,  a  new  model  must  be  developed  for 
network  operations.  This  paper  researches  an  improved  model  for  fleet  network 
operations  management  for  distributed  sea-based  forces  using  existing  teehnologies. 
Combining  a  collaborative  tool.  Decision  Support  System  (DSS),  and  Augmented  Reality 
(AR)  imagery  transforms  Navy  information  network  management  from  a  “minimum 
threshold”  to  an  “operations  fusion”  perspeetive.  Eittle  is  known  about  AR  teehnologies, 
but  the  potential  exists  for  virtual  network  operations  centers  that  can  remotely  direet 
networks  for  sea  and  shore  assets  through  collaborative  efforts.  The  DSS  provides  models 
for  optimization  and  a  knowledge  base  of  potential  actions  (corrective  and  preventative). 
The  product  of  this  paper  will  serve  as  a  baseline  for  network  operations  in  the  network 
eentric  environment.  Eurther  research  would  support  the  development  of  heterogeneous 
virtual  command  and  control  environments. 

B,  GENERAL 

This  researeh  seeks  an  improved  model  for  managing  fleet  information 
frameworks.  It  will  identify  the  principal  capabilities  that  must  be  incorporated  for  future 
fleet  network  operations  eenters.  It  will  also  provide  the  general  design  for  teehnologies 
identified  as  beneficial  to  network  operations.  The  processes  involved  with  network 
operations  will  certainly  change  with  the  introduction  of  new  teehnologies  but  this  paper 
does  not  address  those  changes. 

1,  Research  Questions 

This  researeh  was  started  with  the  goal  of  improving  network  operations.  Two 
questions  were  identified  to  maintain  the  researeh  focus  and  they  are  as  follows. 

a.  Establish  a  collaborative  DSS  model  that  improves  network  operations 
for  distributed  sea  based  forces  using  existing  hardware  and  software. 

b.  Incorporate  AR  technology  for  real-time  collaboration  and  improved 
visualization  of  network  performance 
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2,  Network  Management 

Network  management  is  the  eore  funetion  that  will  be  addressed.  Network 
management  permits  the  effeetive  use  of  information  systems  by  users.  Network 
management  is  eurrently  aeeomplished  by  three  network  operations  eenters  (NOC)  and 
serves  the  entire  fleet  in  exeess  of  300  ships  and  submarines.  Eaeh  NOC  is  assigned  a 
partieular  area  of  responsibility  and  they  are  responsible  for  any  number  of  units  loeated 
within  a  vast  geographie  area.  This  potentially  ereates  disjointed  information 
management  as  ships  transit  between  areas  of  responsibility.  There  is  also  the  ehallenge 
of  eommunieating  with  ships  in  other  areas  depending  on  operational  requirements.  There 
is  a  eumbersome  proeess  involved  for  the  NOC  to  transfer  a  fleet  unit  to  another  area  and 
this  does  not  suit  a  dynamie  operational  environment  well.  Sinee  eaeh  NOC  is 
responsible  for  a  large  seale  network,  it  does  not  have  the  ability  to  manage  speeific 
deviees  aeross  the  various  subnetworks  that  exist  in  the  fleet. 

The  role  of  network  management  is  even  more  important  with  the  emergenee  of 
FORCEnet  and  its  goal  to  integrate  information  systems  aeross  platforms  and  systems. 
This  eannot  be  aehieved  under  the  eurrent  system  of  network  management.  This  researeh 
will  identify  the  eapabilities  required  to  eonduet  network  management.  Many  of  the 
funetions  are  being  used  today,  but  the  major  differenee  is  that  the  eapabilities  identified 
in  this  paper  ean  be  easily  ineorporated  on  eaeh  fleet  asset.  Instead  of  ships  requiring  an 
area  NOC  to  manage  networks,  they  beeome  the  managers.  These  roles  ean  be  easily 
transferred  among  members  of  a  strike  group  or  operation  so  the  deeision-making  rights 
for  the  network  reside  at  the  proper  level.  For  example,  who  should  manage  the 
unmanned  aerial  vehieles  (UAV)  that  are  beeoming  eommonplaee  in  the  fleet  providing 
surveillanee,  targeting,  and  eommunieation  links?  An  area  NOC  eannot  effeetively 
manage  this  level  of  network  granularity  for  users.  Instead,  network  management  roles 
for  this  deviee  should  be  plaeed  with  the  fleet  unit. 

3.  Collaboration  Tool  Suite 

The  primary  means  area  NOCs  eurrently  use  to  eommunieate  is  telephone  or 
email.  There  is  very  little  information  sharing  or  eoordination  aeeomplished  aeross  area 
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boundaries  or  with  fleet  units.  Typically,  the  NOC  will  only  communicate  with  users  if  a 
problem  exists.  Adding  electronic  collaborative  tools  will  provide  significant  rewards  to 
the  network  operations  environment. 

Collaboration  allows  for  better  communication  and  improved  decision  making 
effectiveness  for  groups.  Integrating  collaboration  with  network  operations  lets 
commands  get  involved  with  the  process.  This  is  where  the  “operations  fusion”  change 
can  really  take  place.  A  variety  of  people,  each  with  their  own  perspective,  could  share 
the  same  real-time  network  information.  Instead  of  relying  on  one  or  two  watch  standers 
in  a  NOC  to  interpret  network  performance  information,  now  many  people  are  evaluating 
the  situation.  Network  performance  is  enhanced  and  each  individual  gains  knowledge 
from  the  information  exchange  as  the  group  interacts.  Collaboration  also  allows 
interactive  training  and  information  dissemination  to  easily  occur  within  the  network 
operations  environment. 

This  research  will  identify  the  collaboration  features  that  can  be  used  within 
network  operations.  A  specific  solution  can  be  determined  once  the  individual 
capabilities  are  identified.  Once  the  solution  is  identified,  it  must  obtain  the  DOD 
Collaborative  Tool  Suite  interoperability  certification  also  discussed  in  this  paper. 

4,  Decision  Support  System 

Decision  Support  Systems  (DSS)  are  already  part  of  network  management  suites 
in  a  limited  capacity.  For  example,  most  network  management  suites  maintain  a  database 
to  store  performance  statistics,  which  provide  SNMP  support  including  a  knowledge  base 
of  Management  Information  Bases  (MIBs). 

Although  certain  DSS  components  are  included  in  existing  network  management 
suites,  these  tools  do  not  provide  the  necessary  level  of  support  to  the  decision  maker. 
The  Fleet  network  environment  is  dynamic  and  complex  and  already  takes  significant 
effort  to  effectively  manage.  The  current  level  of  complexity  will  pale  in  comparison  to 
networks  of  the  future.  Network  research  is  ongoing  regarding  peer-to-peer,  self-aware, 
and  self-healing  networks.  Those  systems  require  new  distributed  DSS  solutions  that 
reach  back  to  self-organizing  networking  clusters.  An  improved  system  must  be 
developed  to  provide  improved  support  to  network  managers  to  manage  this  complexity 
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and  this  can  be  found  in  DSS  technology.  This  research  will  identify  the  basic  DSS 
functions  that  will  give  future  network  managers  the  ability  to  properly  manage 
increasingly  complex  networks. 


C.  MEASURES 

The  purpose  of  this  research  is  to  transform  current  fleet  network  operations  with 
multiple  technologies.  This  is  more  than  a  collection  of  individual  tools  however.  This 
research  is  an  innovative  combination  that  considers  the  users,  the  technologies,  the 
software,  and  the  environment  in  which  operations  will  occur.  There  is  also  multi¬ 
dimensional  approach  to  this  research  since  analytical  and  experimental  methods  are  used 
together. 

1.  Evaluate  Current  Fleet  Network  Operations  Model 

Once  the  research  questions  were  identified,  the  next  logical  step  was  to  establish 
the  current  means  the  Fleet  uses  to  accomplish  network  operations.  This  was 
accomplished  by  visiting  the  Pacific  Region  NOC  in  Hawaii  and  several  surface 
combatants.  Each  site  provided  a  wealth  of  information  regarding  the  state  of  network 
operations. 

There  are  other  entities  involved  with  Fleet  network  operations  that  needed  to  be 
contacted.  Specifically,  the  Space  and  Naval  Warfare  Systems  Command  (SPAWAR). 
SPAWAR  is  responsible  for  a  variety  of  Fleet  activities  but  this  research  was  interested  in 
the  configuration  management  accomplished  by  its  system  center  in  Charleston,  SC. 
SPAWAR  also  maintains  a  technical  website  that  provided  significant  insight  for  network 
operations. 

2.  Identify  the  Network  Management  Functions  Required  for  the 
Transformed  Network  Operations  Environment 

This  section  is  the  core  function  of  the  transformed  network  operations  model. 
The  overall  purpose  of  this  research  is  to  create  a  better  way  to  manage  fleet  information 
networks.  Many  of  the  functions  that  are  currently  performed  will  continue  to  be  valid. 
Other  functions  that  are  not  currently  in  place  may  be  added  to  further  the  ability  of 
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future  network  operations  for  the  fleet.  This  research  seeks  to  identify  the  baseline 
network  management  functions  that  should  be  incorporated  into  the  transformed  network 
operations  model. 

3.  Apply  the  Department  of  Defense  Collaborative  Tool  Suite  (DCTS)  to 
the  Transformed  Network  Operations  Environment 

DCTS  is  an  important  consideration  since  collaborative  tools  play  a  part  in  the 
transformed  network  operations  model.  Any  collaborative  tool  that  will  be  installed  on 
DOD  networks  must  earn  a  DCTS  certification.  This  research  identified  the  DCTS 
program,  its  requirements,  and  the  various  testing  procedures  to  facilitate  implementation 
of  the  improved  model. 

4,  Determine  DSS  Architecture  for  Network  Operations 

The  next  step  in  establishing  a  transformed  network  operations  model  called  for 
the  development  of  the  DSS  architecture.  The  DSS  architecture  is  the  framework  that  will 
ease  the  burden  for  users  conducting  network  management.  DSS  is  intended  to  “support 
the  decision-making  process’’^  performed  by  humans.  This  is  a  critical  aspect  to  the 
transformed  network  operations  model  because  people  will  make  key  decisions  regarding 
network  performance  and  set-up.  Some  of  the  more  routine  tasks  may  be  automated  but 
these  are  only  intended  to  alleviate  the  burden  provide  for  the  human  in  the  loop.  This 
research  will  identify  the  underlying  structure  for  DSS  functions. 

5,  Ascertain  the  viability  of  Augmented  Reality  Technology  for 
Improving  Network  Visualizations 

Applying  augmented  reality  (AR)  technology  is  the  most  innovation  addition  to 
network  operations.  In  fact,  there  are  very  few  AR  applications  that  have  gone  beyond  the 
prototype  stage.  This  technology  provides  computer  generated  text,  graphics,  or  images 
and  overlays  them  onto  the  user’s  real-world  sensory  inputs.  This  may  potentially  bring  a 
tremendous  capability  jump  for  collaboration  and  visualization  for  network  managers. 
This  research  will  determine  if  AR  is  appropriate  to  the  network  operations  environment. 

6.  Test  and  Evaluate 

In  order  to  correctly  identify  the  network  operations  model,  testing  and  evaluation 
must  occur.  The  steps  taken  here  will  validate  concepts  that  were  discovered  while 
conducting  research  in  other  areas.  The  testing  conditions  that  will  be  evaluated  will  vary. 

5  Decision  Support  Systems  in  the  2D‘  Century,  George  M.  Marakas,  Prentiee  Hall,  1999 

6 


To  illustrate  this,  the  evaluation  of  network  management  packages  will  be  very  close  to 
the  actual  measures  taken  later.  In  the  case  of  AR  technology,  the  evaluation  is  based  on 
simulated  factors  since  AR  programs  development  is  outside  the  scope  of  this  paper.  The 
end  goal  of  this  portion  is  to  corroborate  the  ideas  discovered  during  research.  The  tests 
here  seek  to  verify  valid  concepts  with  future  testing  providing  specific  implementation 
guidance. 
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II.  EVALUATE  CURRENT  FLEET  NETWORK  OPERATIONS 

METHODS 


A,  DETERMINE  CURRENT  STATUS  OF  FLEET  NETWORK 

OPERATIONS 

Before  considering  what  functions  must  be  incorporated  into  a  transformed 
network  operations  center,  the  existing  capabilities  must  be  identified.  The  Fleet  NOCs 
provide  a  variety  of  services  for  fleet  units  including  basic  connectivity,  email,  Internet 
access,  bandwidth  monitoring,  and  security  functions.  The  FCAPS  model  was  selected  as 
the  framework  in  order  to  effectively  evaluate  and  categorize  the  methods  in  use  at  the 
Fleet  NOCs. 

1.  FCAPS  Model 

FCAPS  is  actually  an  acronym  for  Fault,  Configuration,  Accounting, 
Performance,  and  Security  managements.  The  model  was  developed  by  the  International 
Telecommunications  Union  (ITU)  as  recommendation  M.3400  to  provide  a  structure  for 
network  operations.  The  FCAPS  model  is  organized  by  function  and  describes  the  five 
types  of  information  handled  by  management  systems^.  It  is  the  current  model  that 
industry  and  researchers  use  to  evaluate  network  functions.  Since  the  FCAPS  model  is  so 
relevant  to  information  networks,  it  will  be  used  to  identify  the  methods  used  for  current 
fleet  network  operations. 

a.  Fault  Management 

Fault  management  is  defined  as  the  “functions  which  enable  the  detection, 
isolation,  and  correction  of  abnormal  operation  of  the  telecommunications  network  and 
its  environmenf’8.  The  categories  included  within  fault  management  are  quality 
assurance  for  RAS  (reliability,  availability,  and  survivability),  alarm  surveillance, 
localization,  correction,  testing,  and  administration  (ex  trouble  ticket).  In  brief,  this 
section  of  the  model  is  concerned  with  discovering,  correcting,  and  correcting  network 
problems. 


6  ITU-T  Recommendation  M.3400  (02/2000),  TMN  Management  Functions 

7  http://www.iec.org/online/tutorials/ems/topic3.html,  Feb  04 

8  ITU-T  Recommendation  M.3400  (02/2000),  TMN  Management  Functions 
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Since  the  fleet  NOCs  serve  a  highly  mobile  and  distributed  fleet,  the  fault 
management  functions  are  extremely  important.  When  eonsidering  fault  management,  the 
fleet  NOCs  are  most  eoneerned  with  maintaining  network  conneetivity  between  various 
nodes.  The  NOCs  use  multiple  software  paekages  to  monitor  fleet  eonneetivity. 
IPSWITCH’S  What’s  Up  Gold  (WUG)  is  the  primary  network  management  suite  and 
provides  a  variety  of  information  about  network  performanee  using  SNMP  and  ICMP 
management  tools.  NOC  personnel  view  status  about  eonneetions  and  equipment  (ex., 
servers)  for  the  overall  network  and  the  software  paekages  are  eonfigured  so  NOC 
personnel  may  quiekly  reeognize  a  problem  when  it  oeeurs.  If  the  problem  is  signifieant 
enough  (aoeording  to  established  NOC  policies)  personnel  may  be  automatieally  notified 
with  an  email  or  pager  message  by  the  software.  Periodieally  NOC  wateh  standers  check 
the  status  of  their  end-users  but  the  primary  focus  is  on  overall  network  eonneetivity.  The 
NOC  does  not  generally  look  at  the  situation  for  individual  users  unless  they  are  notified 
of  a  problem.  This  usually  oeeurs  when  a  user  reports  a  loss  of  aeeess  to  the  network  or 
experienees  an  inability  to  perform  network  related  tasks  (ex.,  send  email).  The  NOC 
does  have  a  eapability  to  view  eertain  parameters  for  the  user  through  the  embedded. 
Although  WUG  ineorporates  SNMP,  the  two  main  methods  used  by  the  NOC  to  quiekly 
determine  network  eonneetivity  are  ICMP  (ex.,  PING  functions)  and  TELNET.  These 
methods  are  also  used  to  determine  what  serviees  are  in  use  and  to  discover  problems. 

Part  of  the  fault  management  funetion  is  aeeomplished  by  the  dual  path 
fleet  network  arehiteeture.  Sinee  there  is  more  than  one  path  in  the  fleet  network,  the 
impaet  of  a  easualty  is  greatly  redueed.  At  any  given  time,  all  network  paths  are  used  to 
maximize  the  effeetive  bandwidth.  If  a  path  failure  oeeurs,  the  network  bandwidth  is 
redueed  by  fifty  percent.  Users  will  maintain  aeeess  to  serviees  but  at  a  redueed  eapaeity. 
When  a  path  failure  does  oecur,  the  NOC  sends  a  radio  traffic  message  to  the  affeeted 
users  notifying  of  the  problem. 

Another  eoneern  for  the  NOC  is  the  status  of  the  fleet  router.  The  fleet 
router  is  an  enterprise  level  COTS  router  that  manages  network  traffic  flow  for  fleet 
users.  This  is  a  eritieal  deviee  in  the  fleet  network  and  a  problem  with  this  equipment 
eould  eause  fleet  users  a  eomplete  loss  of  network  availability.  If  problems  are  discovered 
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with  the  fleet  router,  the  NOC  will  attempt  to  reeonneet  to  the  router.  If  this  fails,  the 
NOC  attempt  to  resolve  the  problem  using  ICMP  and  TELNET  funetions. 

b.  Configuration  Management 

Conflguration  management  is  deflned  as  the  “functions  to  exercise  control 
over,  identify,  collect  data  from  and  provide  data  to  network  elements ”9.  The  areas 
residing  within  configuration  management  are  network  planning  and  engineering, 
installation,  service  planning  and  negotiation,  provisioning,  and  status  and  control. 

The  Fleet  NOCs  do  not  currently  manage  the  configuration  of  software  of 
hardware  or  software  that  reside  at  each  location.  The  program  executive  office  (PEO)  for 
Command,  Control,  Communications,  Computers,  and  Intelligence  (C4I)  is  responsible 
for  establishing  the  configuration  policy  for  the  network  operations  centers.  Ideally,  the 
PEO  C4I  office  sets  the  policy  that  determines  the  appropriate  hardware  and  software. 
After  policy  is  set,  the  necessary  systems  are  acquired,  and  finally  they  are  accounted  for 
and  tracked.  Only  those  systems  identified  by  the  PEO  C4I  staff  should  be  installed  into 
the  NOC.  The  activity  responsible  for  maintaining  configuration  information  for  the 
NOCs  is  the  Naval  Space  and  Naval  Warfare  Command  (SPAWAR).  More  specifically, 
the  SPAWAR  center  responsible  is  located  in  Charleston,  South  Carolina  and  has  a 
database  that  includes  serialized  hardware,  software,  and  the  appropriate  network 
topologies.  Each  piece  of  equipment  may  have  a  variety  of  information  associated  with  it 
including  trouble  tickets,  casualty  reports  (CASREPS),  and  other  pertinent  information  so 
that  a  history  is  collected. 

Unfortunately  this  database  has  not  been  maintained  properly  because  of 
budgeting  constraints.  As  a  result,  the  current  NOC  configuration  is  a  combination  of 
authorized  (and  documented)  systems  in  addition  to  systems  developed  in-house  by  NOC 
personnel.  SPAWAR  SYSCEN  Charleston  does  not  have  functional  system  to 
accomplish  configuration  management.  Each  NOC  maintains  there  own  set  of  hardware 
and  software  but  there  is  little  coordination  between  the  area  NOCs. 

c.  Accounting  Management 

Accounting  measurement  is  defined  as  “the  measurement  of  the  use  of 
network  services  and  the  determination  of  costs  to  the  service  provider  and  charges  to  the 
9  ITU-T  Recommendation  M.3400  (02/2000),  TMN  Management  Functions 
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customer  for  such  use”io.  Accounting  management  includes  usage  measurement,  tariffing 
and  pricing,  collection  and  finance,  and  enterprise  control.  This  part  of  the  FCAPS  model 
is  normally  concerned  with  ensuring  the  customer  is  appropriately  billed  for  the  services 
delivered.  The  typical  functions  associated  with  accounting  management  do  not  apply  to 
fleet  assets  as  in  the  commercial  sector. 

Electronic  mail  (email)  had  evolved  into  a  requirement  onboard  ships  to 
conduct  a  variety  of  business.  Email  has  emerged  as  a  mission  essential  tool  for  ships 
because  it  provides  the  capability  to  coordinate  and  communicate  and  each  ship  has  their 
own  domain  email  server.  To  facilitate  this,  NOCs  can  create  and  delete  email  accounts 
from  mail  servers  for  individual  ships  and  also  monitor  email  usage  through  custom 
scripts  developed  by  NOC  personnel.  As  a  backup  to  this,  the  NOCs  maintain  an  alternate 
email  capability  for  ships  using  the  Internet  Message  Address  Protocol  (IMAP).  IMAP 
allows  ships  to  dial-up  to  a  mail  server  located  at  the  NOC  and  access  mail  messages  if 
the  primary  method  is  unavailable. 

Unlike  fixed  network  installations  at  stationary  sites.  Navy  ships  transit 
around  the  world  to  accomplish  missions.  This  further  complicates  the  role  of  the  NOC 
because  as  ships  move  from  one  area  of  responsibility  to  another,  the  appropriate  NOC 
must  assume  the  responsibility  for  ship’s  network  connectivity.  There  are  procedures  in 
place  to  allow  the  transfer  of  responsibility  between  NOCs  as  dictated  by  operational 
requirements. 

The  accounting  management  functions  for  fleet  assets  are  limited  mostly 
to  bandwidth  allocation  issues.  Ships  are  provided  connectivity  through  several  means. 
These  include  military  specific  network  to  commercial  satellite  networks  with  pre¬ 
negotiated  leases  appropriate  for  the  operational  environment  for  each  unit  or  group.  Eor 
example,  a  ship  that  is  deployed  overseas  likely  has  a  steady  amount  of  bandwidth 
allocated.  Eor  ships  that  are  not  deployed  and  are  only  conducting  local  training 
evolutions  at  sea,  the  bandwidth  allocation  may  be  limited  to  certain  times  of  day  so  that 
unit  may  conduct  routine  business  like  email  or  web  services.  Regardless  of  the  amount 
allocated,  ships  are  not  responsible  for  the  bill  associated  with  network  connectivity.  The 

10  ITU-T  Recommendation  M.3400  (02/2000),  TMN  Management  Functions 
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NOC’S  manage  the  resource  allocation  to  fleet  units  according  to  the  operational  context 
using  a  variety  of  tools.  They  use  PacketShaper  (from  Packeteer)  software  and  routers  to 
monitor  and  manage  the  bandwidth  used  by  ships. 

d.  Performance  Management 

Performance  management  is  defined  as  the  “functions  to  evaluate  and 
report  upon  the  behavior  of  telecommunication  equipment  and  the  effectiveness  of  the 
network  or  network  element”!  k  Several  categories  of  functions  occur  within  the 
performance  management  domain  including  Quality  of  Service  (QoS),  quality  assurance, 
monitoring,  control,  analysis,  and  testing. 

Industry  research  results  suggest  that  IT  Managers  spend  thirty  percent  of 
their  time  attempting  to  discover  what  is  causing  network  performance  degradationsi2. 
This  indicates  the  importance  performance  management  plays  for  network  operations. 
The  addition  of  performance  management  software  in  the  NOCs  is  an  indication  that  this 
concern  is  reflected  in  the  Fleet  NOCs.  The  primary  software  the  NOCs  use  is  called 
PacketShaper  and  is  focused  on  four  areas  of  performance  management.  The  software 
provides  increased  application  visibility  because  it  can  see  different  types  of  traffic  based 
on  common  networking  standards.  For  example,  the  software  can  differentiate  between 
HTTP  used  in  web  browsing  or  Voice  Over  Internet  Protocol  (VoIP)  packets.  It  lets 
network  managers  control  the  types  of  information  flowing  across  the  network  according 
to  organizational  goals  because  the  software  can  restrict  protocols  and  packet  types 
completely  or  to  a  percentage  of  the  available  information  capacity.  The  software  also 
uses  compression  to  improve  the  use  of  bandwidth  and  provides  centralized  management 
of  reports,  analysis,  and  administration.  This  software  looks  at  higher  network  layers  than 
standard  network  management  suites  which  grants  network  administrators  tremendous 
capabilities.  The  NOCs  use  Sitescope  software  (from  Mercury  Interactive)  to  determine 
system  health  for  hardware,  and  “link”  status  to  monitor  the  connection  to  ships. 

An  important  function  that  occurs  in  fleet  network  operation  centers 
(NOC)  is  maintenance  of  data  logs.  The  logs  contain  a  record  of  center  activities  and 
include  real-time  information  about  network  events  and  performance.  User  generated  log 

11  ITU-T  Recommendation  M.3400  (02/2000),  TMN  Management  Functions 

12  http://www.nwfusion.eom/news/2003/1201apm.html,  Feb  04 
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entries  must  be  pertinent  and  aeeurate  to  properly  deseribe  the  operational  history  of 
information  networks.  Automatie  log  entries  are  also  generated  by  network  management 
software  paekages.  The  subjeet  matter  of  the  logs  may  inelude  situation  reports, 
signifieant  events,  system  faults  (or  casualties),  troubleshooting  efforts,  trouble  tickets, 
circuit  activation  and  deactivation,  personnel  matters,  and  other  information. 

e.  Security  Management 

Security  management  is  defined  as  “the  management  of  security”  and 
includes  prevention,  detection,  containment,  recovery,  administration  functional 
categories.  The  Department  of  Defense  is  a  highly  visible  target  for  malicious  network 
activities  and  as  such  security  management  is  an  area  that  must  be  properly  addressed. 
The  DOD  is  very  concerned  with  security  because  of  the  importance  information 
networks.  Although  a  very  important  subject  area,  this  paper  will  only  address  a  narrow 
portion  of  network  security. 

The  policies  for  the  Navy’s  network  security  are  established  by  the  Chief 
of  Naval  Operations  (CNO)  for  the  entire  department,  which  fleet  networks  are  a 
component.  The  Naval  Network  Warfare  Command  (NETWARCOM)  and  its 
subordinate  commands  serve  as  the  CNO’S  primary  advisors  for  network  security 
policies.  These  policies  and  instructions  are  in  addition  to  those  promulgated  by  the 
DOD. 

Network  operations  centers  are  involved  with  several  aspects  of  network 
security.  The  broad  areas  of  interest  include  ensuring  only  authorized  users  gain  access, 
information  confidentiality  and  integrity  is  maintained  on  the  network,  and  network 
services  are  available  to  the  appropriate  users. 

Information  logs  were  mentioned  under  performance  management  but 
they  also  play  a  role  with  security  management.  Manual  and  automatic  logs  indicate  the 
aggregate  network  activity  history  and  trend  information  for  NOC  personnel  that  real¬ 
time  displays  cannot  easily  present.  Once  the  data  is  analyzed,  a  determination  can  be 
made  to  see  if  network  attacks  or  other  unusual  behavior.  Access  logs  are  also  maintained 
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to  provide  a  layer  for  physical  security  since  visitors  may  enter  NOC  spaces.  The 
information  included  in  these  logs  often  includes  the  visitor  badge  number  and  name  of 
the  appropriate  escort. 

Fleet  firewall  management  is  a  big  part  of  the  security  function  performed 
by  the  regional  NOCs.  A  firewall  is  a  “device  that  has  a  set  of  rules  specifying  what 
traffic  it  will  allow  or  deny”i3.  As  previously  mentioned,  the  NOCs  are  responsible  for 
enacting  the  policies  set  forth  by  upper  level  commands.  Firewall  policies  are  established 
by  senior  members  of  the  NOC  chain  of  command  and  the  NOC  implements  those  policy 
decisions.  To  preserve  the  security  of  fleet  networks,  specific  settings  will  not  be 
discussed.  Instead,  the  concepts  most  relevant  to  the  NOCs  will  be  discussed  in  generic 
way.  First,  only  authorizes  users  can  communicate  through  fleet  firewalls  with  trusted 
systems.  The  NOCs  maintain  the  authority  to  authorize  or  restrict  access  to  the  Firewall 
for  communication.  This  does  not  include  the  delegation  of  administrator  privileges  as 
they  are  reserved  for  the  NOC.  Another  part  of  the  NOC’S  responsibility  for  firewall 
management  includes  managing  telnet,  FTP,  and  other  protocols  that  may  cross  the 
firewall.  Often  these  protocols  are  used  to  infiltrate  systems  because  of  security  flaws  in 
the  standard.  The  NOC’S  implement  and  maintain  the  specific  criteria  (ex.,  port  numbers 
and  device  settings)  so  only  authorized  entities  use  these  protocols  for  legitimate 
purposes. 

Lastly,  the  NOC’S  maintain  virus  scanning  software  for  the  entire  network 
in  another  attempt  to  prevent  malicious  attacks.  These  systems  exist  for  individual 
devices  and  for  overall  network  traffic. 

B,  USER-INTERFACE  BETWEEN  HARDWARE  AND  SOFTWARE 

1.  Shore  Assets 

The  three  Fleet  NOCs  are  the  shore  assets  we  address  here.  Each  NOC  uses  the 
network  management  suite  What’s  Up  Gold  and  a  performance  management  solution 
called  PacketShaper,  and  Sitescope. 


13  Inside  Network  Perimeter  Seeurity,  Northeutt  et  al,  New  Riders  Publishing,  2003 
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The  What’s  Up  Gold  interface  combines  graphical  and  textual  information  to 
provide  network  status  information.  It  provides  a  “network  map”  display  so  at  a  quick 
glance  users  can  see  the  status  of  network  devices.  There  are  also  more  detailed 
presentations  that  give  specific  performance  criteria.  It  is  a  commercial  network 
management  solution  used  in  each  NOC.  PacketShaper  uses  software  and  hardware  and 
allows  network  managers  to  view  network  performance  information  at  higher  levels  than 
typical  network  management  suites.  It  provides  network  managers  the  ability  to  monitor 
specific  types  of  applications  and  protocols,  control  traffic  flow,  and  compress  traffic  for 
more  efficient  use  of  bandwidth.  The  NOCs  also  use  applications  that  are  developed  by 
on-site  personnel.  These  are  unique  to  each  NOC  and  maintained  by  their  developers. 

2,  Sea-based  Commands 

Fleet  users  are  all  sea  based  commands.  With  few  exceptions.  Navy  ships  and 
submarines  have  local  area  networks  installed  at  part  of  the  Information  Technology  for 
the  2U*  Century  (IT21)  initiative.  After  visiting  different  platform  types,  there  is  no 
existing  capability  for  ships  or  submarines  to  act  as  a  network  operations  center.  The 
primary  role  for  personnel  onboard  ships  is  to  conduct  server  administration,  establish 
connectivity  with  the  fleet  network,  and  perform  the  necessary  maintenance  actions  to 
keep  the  shipboard  network  functional.  Shipboard  personnel  are  able  to  determine  if 
connectivity  exists  but  they  cannot  manage  it.  There  is  also  no  ability  for  shipboard 
personnel  to  gather  information  about  connections  from  other  nodes  within  the  network. 


C.  IDENTIFY  NOC  COORDINATING  MECHANISMS 

The  chain  of  command  for  the  network  operations  centers  must  be  explained  in 
order  to  properly  identify  the  procedures  and  coordination  mechanisms  for  the  fleet 
NOCs.  There  are  three  network  operations  centers  located  in  Hawaii  and  Virginia  that 
perform  network  operations  management  for  the  fleet.  They  are  an  internal  part  of  the 
Naval  Computer  and  Telecommunication  Area  Master  Station  (NCTAMS)  Atlantic  and 
Pacific  commands. 

Administratively,  the  NCTAMS  immediate  superior  in  the  chain  of  command 
(COC)  is  the  Naval  Computers  and  Telecommunications  Command  (NCTC).  The  NCTC 

in  turn  reports  to  the  head  of  the  navy  for  communications  and  computer  policies,  the 
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CNO  N6  office.  This  organizational  chain  of  command  is  mainly  concerned  with 
identifying  the  requirements,  plans,  systems,  policies  and  manpower  related  to  Joint 
(multiple  DOD  services)  communications  for  the  Navy.  A  significant  portion  of  the  work 
accomplished  here  is  the  generation  of  funding  priorities  so  the  Navy  can  accomplish  its 
mission.  The  operational  COC  has  more  impact  on  day-to-day  NCTAMS  operations  than 
the  administrative  COC.  Operationally,  the  NCTAMS  receive  direction  from  the  fleet 
commanders  (Atlantic  and  Pacific  Fleets).  The  Fleet  commanders  serve  as  the  Navy 
element  to  US  Component  Commanders  (ex.,  USPACOM).  The  component  commanders 
report  to  the  President  and  Secretary  of  Defense  through  the  Joint  Chiefs  of  Staff. 

The  fleet  unit  (ex.,  destroyer)  unfortunately  doesn’t  necessarily  realize  the  effect 
the  senior  COC  has  on  network  operations  because  it  may  not  be  visible.  Individual  fleet 
assets  are  the  apparatus  of  policies  set  by  the  upper  echelon  commands  and  do  not  always 
perceive  the  various  issues  involved  considering  the  scope  of  the  entire  fleet.  The  fleet  is 
participating  in  real-world  operations  and  exercises  at  any  given  time.  NCTAMS  receive 
prioritization  direction  about  network  resource  allocation  from  the  Fleet  commanders. 
NCTAMS  can  then  establish  which  units  are  most  relevant  to  the  current  mission 
requirements  and  provide  network  services  accordingly.  The  NOCs  act  as  the 
intermediaries  between  the  upper  echelon  commands  and  the  fleet  units  because  they 
enact  policies  manage  network  resources  accordingly.  As  a  result,  the  fleet  assets  are  the 
end  user  in  the  process  since  they  receive  the  network  resource  and  services. 

For  example,  assume  two  ships  are  underway  and  require  satellite  connectivity. 
Ship  “A”  is  part  of  a  deployed  Carrier  Strike  Group  while  Ship  “B”  is  conducting  local 
training  operations.  Since  this  operational  context  is  provided  by  the  Fleet  Commander 
staff,  the  NOC  can  allocate  resources  accordingly.  In  this  case.  Ship  “A”  receives  the 
necessary  resources  based  on  the  approved  set  of  priorities  provided  to  NCTAMS.  On  the 
other  hand.  Ship  “B”  is  allocated  resources  by  the  NOC  from  the  remaining  network 
capacity  since  they  are  only  conducting  local  training  operations. 

The  situation  also  illustrates  the  need  to  increase  the  situational  awareness  for 
future  network  operations  centers.  The  awareness  between  the  NOC  and  individual  fleet 
units  is  typically  low  since  there  is  limited  organizational  coordination.  Each  regional 
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NOC  has  approximately  five  personnel  on  duty  including  a  supervisor  at  any  given  time. 
This  will  vary  depending  on  the  operational  requirements  (and  region)  but  this  makes  it 
very  difficult  to  maintain  an  overall  picture  of  network  performance.  The  personnel  in  the 
NOC  will  float  among  tasks  as  needed  and  there  is  no  regular  communication  occurring 
between  entities  (ex.,  NOC  to  ship)  unless  a  problem  develops  with  the  network.  This 
does  not  lend  itself  to  fully  effective  network  operations.  Future  network  operations  will 
require  all  network  participants  to  share  a  common  picture.  The  methods  to  accomplish 
this  are  addressed  later  in  this  research  but  increasing  communication  and  network 
visualization  among  all  participants  greatly  increases  the  effectiveness  of  the  network. 
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III.  APPLYING  THE  DEFENSE  COLLABORATIVE  TOOL  SUITE 
TO  THE  NETWORK  OPERATIONS  ENVIRONMENT 

A,  WHAT  IS  DCTS? 

1.  Background 

Historically,  the  individual  components  within  the  United  States  Department  of 
Defense  (DOD)  acquired  systems  individually  without  respect  to  the  other  services.  For 
example,  if  the  Army  and  Navy  were  trying  to  purchase  tactical  two-way  radio  systems, 
there  was  probably  no  discussion  between  the  two  services  about  system  requirements. 
There  would  also  be  no  discussion  between  the  services  regarding  the  interoperability  of 
those  radio  systems. 

A  major  DOD  restructuring  took  place  as  a  result  of  the  Goldwater-Nichols 
Department  of  Defense  Reorganization  Act  of  1986.  The  new  law  affected  the  highest 
levels  of  the  military  through  centralization  of  operational  authority  and  a  streamlined 
military  chain  of  commandi4.  The  most  notable  result  of  the  Goldwater-Nichols  Act  was 
to  require  the  DOD  to  operate  in  a  joint  manner.  In  other  words,  the  Act  required  the 
services  to  be  able  to  work  together  and  have  interoperable  systems.  Even  though  the 
Goldwater-Nichols  Act  was  passed  in  1986,  the  DOD  was  very  slow  to  respond  to  the 
requirement  to  work  jointly.  The  Government  Accounting  Office  (GAO)  strongly 
criticized  the  DOD  for  its  efforts  as  recently  as  199815.  The  United  States  Congress 
(Congress)  specifically  instructed  the  DOD  to  address  the  lack  of  collaborative  tool 
interoperability  in  1999. 

In  response  to  Congressional  pressure,  the  Office  of  the  Secretary  of  Defense 
(OSD)  and  the  Joint  Staff  created  the  Collaboration  Tiger  Team  (CTT)16.  The  members 
of  the  team  included  Combatant  Commanders  (formerly  known  as  CINCs),  Service 
representatives,  and  other  federal  agencies.  The  CTT  received  a  two  part  mission.  The 
first  requirement  was  to  establish  the  strategic  guidance  for  the  DOD  to  employ 
collaborative  tools.  Based  on  the  strategy  it  created,  the  next  step  was  to  define  and 

1 4  http  ://www.  ndu .  edu/library/ go Idnich/ go Idnich .html 

15  GAO  Letter  1993,  1998 

15  http://www.jitcwashops.disa.mil/projects/jtcb_dcts.htm 
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validate  the  funetional  requirements  for  DOD  collaborative  tools.  The  functional 
requirements  list  was  instituted  so  the  more  important  aspects  were  given  a  higher 
priority. 

With  a  mission  in  place,  the  CTT  obtained  support  from  the  Joint  Command, 
Control,  Communications,  Computers,  Intelligence,  Surveillance,  and  Reconnaissance 
(C4ISR)  Battle  Center  (JBC)  to  conduct  assessments  of  DOD  collaborative  tools  with  a 
Joint  Task  Force  (JTF).  The  results  of  these  assessments  became  the  Collaboration  Tool 
Suite  (CTS)  and  were  submitted  in  September  2000  as  the  CTT  recommendation  for  an 
interim  standard  for  the  DOD.  The  CTS  was  approved  in  January  200117  and  became  the 
Defense  Collaboration  Tool  Suite  (DCTS).  DCTS  is  a  baseline  that  the  Collaboration 
Management  Office  (CMO)  uses  to  ensure  interoperability  between  products  originating 
from  different  vendors.  CMO  is  part  of  the  Defense  Information  Systems  Agency  (DISA) 
and  will  partially  subsidize  DCTS  testing  under  a  program  called  the  Collaboration 
Interoperability  Partnership  Testing  Program  (CIPTP). 

2.  The  Scope  of  DCTS  Requirements 

The  following  tables  indicate  the  requirements  for  DCTS  certificationis. 

Table  1.  Collaborative  Functions  Requiring  DCTS  Certification 

Voice  Conferencing 
Video  Conferencing 
File  Sharing 
Application  Sharing 
Awareness 
Instant  Messaging 
Whiteboarding 

Table  2.  Case  by  Case  DCTS  Determination 

Websites 
Webportals 

Office  Automation  Packages 
IV  SECDEF  MSG  DIG  291130  Jan  01 

18http://www.jitcwashops.disa.mil/downloadAVho%20Must%20Be%20Tested%20for%20Collaborati 
on%20Interop  erab  ility .  doc 
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Table  3.  Generic  Exceptions  to  DCTS  Certification  Requirement 
Email 

Studio-Type  VTC  (H.320) 

Operating  Systems 

Table  4.  Other  Exemptions 

Appian  Enterprise  (versions  2  and  3) 

ECATS 

GroupSystems  for  Windows,  Workgroup  Edition,  Version  3.4 

GroupSystems  MeetingRoom  ,  Version  4.0 

GroupSystems  Online,  Version  3.4 

Oracle  Collaboration  Suite 

Plumtree  Collaboration  Server,  Version  3.0 

Sitescape  Enterprise  Eorum,  V.7 

ARNG  Snitz  Eorums  2000  V.3.4.03 

USO  Videophone  -  Operation:  In  Sight 

Tomoye  Simplify  3.1 

Eacilitate.com  Version  7.5 

Eacilitate.com  Version  8.0 

Ultimus  Workflow  Suite  Version  5 

Hummingbird  DM,  RM,  Imaging,  DM  Workflow,  Web  Publishing 
(versions  5.0  and  5.1) 

Zaplet  Version  3.0 

Erontier  Technology,  Inc  Integrated  Desktop  Analysis  and 
Planning  System  (ID APS) 


3,  Impact 

The  DOD  Chief  Information  Officer  (CIO)  published  a  memorandum  on 
November  1,  2002  concerning  collaboration  interoperability  standards.  The  memo  states 
that  “all  collaboration  products  used  by  the  Department  must  demonstrate  interoperability 
and  compliance  with  DOD  collaboration  criteria.”  In  that  memo,  the  DOD  CIO  also 
states  that  systems  already  installed  on  DOD  networks  must  demonstrate  interoperability. 
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Since  DCTS  is  a  Department  of  Defense  program,  each  service  (ex.,  US  Navy) 
seeking  to  install  collaborative  tools  onto  their  networks  must  ensure  each  product 
successfully  obtains  the  DCTS  certification.  The  completed  certification  requires 
products  to  be  interoperable  “off-the-shelf’  meaning  that  products  must  not  interfere  with 
other  approved  DCTS  products  without  special  configuration  or  set-up  ahead  of  time. 

To  achieve  the  interoperability  certification,  or  DCTS  approved,  vendors  must 
submit  their  products  through  the  CMO  to  the  Joint  Interoperability  Test  Command 
(JITC)  in  Indian  Head,  Maryland  for  testing. 

DCTS  V  1.1. 12  began  employment  in  April  2002  and  within  six  months  had  sixty- 
two  sites  located  throughout  the  world.  In  2003  DCTS  was  fielded  in  another  62  sites 
including  DOD  Combatant  Commands.  An  enhanced  version  of  DCTS,  v2.0,  was 
scheduled  for  release  in  200319. 

B.  DCTS  REQUIREMENTS 

1,  Vendor  Awareness 

The  first  step  for  a  vendor  to  reach  a  DCTS  certification  is  to  solicit  from  the 
Federal  Government.  This  is  primarily  accomplished  through  the  FedBizOpps  website 
(http://fedbizops.gov),  which  serves  as  the  sole  entry  point  for  Federal  Government 
solicitations  for  procurement  over  $25,000.  Vendors  seeking  to  add  collaborative 
components,  tool  sets,  or  services  should  look  to  this  site  for  Federal  Agency  postings  for 
business  opportunities. 

Once  the  vendor  is  aware  of  the  DCTS  program,  CMO  is  contacted  to  continue 
the  process.  CMO  will  send  a  response  letter  to  the  vendor  with  important  DCTS 
documentation.  The  documents  included  provide  information  about  the  DCTS  baseline, 
testing  procedures,  entrance  criteria,  test  requirements,  fee  schedule,  and  required 
application/testing  agreement.  The  letter  also  contains  the  contact  information  for  JITC 
since  they  will  actually  schedule  and  conduct  the  interoperability  testing  for  the 
product(s). 


19  http://www.fVc.com/eng/usgov/dcts.htm, 
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2,  Vendor  Self-Assessment 

The  second  action  for  the  vendor  is  to  conduct  a  self-assessment  of  the  product 
that  will  be  tested  by  JITC.  This  is  required  because  there  are  three  types  of 
interoperability  tests  and  each  has  a  different  cost.  The  vendor  conducts  the  self- 
assessment  because  any  combination  of  the  tests  is  possible  depending  on  the  product. 
The  product  is  tested  based  on  the  choice  made  by  the  submitting  vendor. 

The  Augmented  Capability  test  is  the  first  type  and  is  the  lowest  level  of  testing 
available.  If  a  product  adds  capability  to  an  existing  DCTS  baseline,  it  is  characterized  as 
an  Augmented  Capability.  This  added  functions  may  be  described  by  “plugging  in”  new 
features  or  replacing  an  existing  capability  with  an  improved  one.  The  fee  associated  with 
this  test  is  $5,000. 

The  middle  level  is  called  Equivalent  Component  Functionality.  Products  to  be 
tested  at  this  level  seek  to  replace  quantifiable  functionality  already  existing  in  DCTS 
products.  In  other  words,  a  product  designed  to  replace  a  DCTS  function  must  be 
interoperable  with  other  DCTS  functions.  The  normal  fee  for  this  test  is  $8,000.  If  the 
product  to  be  tested  is  a  multipoint  control  unit  (MCU),  the  fee  is  $10,000. 

The  highest  level  of  interoperability  is  System  Level.  This  is  the  most  extensive 
set  of  tests  because  the  vendor  is  attempting  to  certify  a  full-featured  collaboration  suite 
for  use  in  the  DOD.  The  test  covers  all  modes  and  functions  of  the  candidate  system  and 
costs  $20,000. 

Table  5.  Types  of  DCTS  Interoperability  Testing20 


Test  Type 

Fee 

Augmented  Capability 

$5,000 

Equivalent  Component  Funetionality 

$8,000  ($10,000  if  MCU) 

System  Level  Testing 

$20,000 

Once  the  vendor  considers  what  type  of  testing  is  desired,  the  product  needs  to  be 
evaluated  against  the  DCTS  Entrance  Criteria  Checklist.  This  checklist  is  broken  down 
into  individual  criterion  by  type.  Each  type  is  listed  with  the  standards  for  each  capability 

20  Testing  Fee  Sehedule  v2 
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residing  within  the  product  to  be  tested.  These  standards  represent  the  minimum  standard 
that  the  product  must  comply  with  to  enter  the  testing  phase. 

3,  Vendor  Initiates  Test 

Once  the  self-assessment  is  completed,  the  Vendor  can  initiate  the  test  process  by 
submitting  the  required  documents  to  JITC. 

The  first  document  is  the  ‘Testing  Application  and  Agreement’.  In  this  document 
the  vendor  acknowledges  various  government  conditions  that  apply  to  the  product 
submission.  Most  importantly,  the  vendor  indicated  the  product(s)  to  be  tested  and  what 
interoperability  test  type(s)  it  will  be  evaluated  against.  The  choices  selected  by  the 
vendor  establish  the  fee  schedule.  Once  both  sides  agree  and  the  application  is  completed, 
it  is  signed  by  Federal  Government  and  vendor  representatives  and  becomes  part  of  the 
product  fde. 

The  second  document  submitted  is  the  ‘Entrance  Criteria  ChecklistA^erification’. 
This  indicates  to  the  government  (JITC)  that  the  product(s)  meet  the  preliminary 
interoperability  testing  criteria  and  the  testing  process  can  continue.  The  following  table 
is  a  summary  of  the  entrance  criteria. 

In  addition  the  vendor  must  include  the  product(s)  documentation  for  JITC 
review.  Lastly,  the  vendor  includes  a  company  check  for  the  amount  established  in  the 
submitted  Testing  Application  and  Agreement’.  Once  the  vendor  supplies  the  necessary 
documentation,  JITC  will  schedule  interoperability  testing. 
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Table  6.  Entrance  Criteria. 


Criterion 

Applicable  Standard  (or 
Reference 

Implementation)  for  DOD 
Collaboration 

Required  For 
Certification 

Product  Supports  this 
Standard? 

(Circle  applicable  response) 

■ 

Coexistence 

DODD  4630.5 
(COE  Level  5  Compliance) 

Yes 

Y  /  N  /  NA 

2. 

Collaborator 

Status 

HTTP,  XML,  SOAP,  via 
published  API 

Yes 

Y  /  N  /  NA 

3. 

Conference 

Discovery 

HTTP,  XML,  SOAP,  via 
published  API 

Yes 

Y  /  N  /  NA 

i 

Virtual  Space 
Discovery 

HTTP,  XML,  SOAP,  via 
published  API 

Yes 

Y  /  N  /  NA 

5. 

Text  conference 
Text  (IM) 

NetMeeting,  SunForum 
Envoke,  Envoke  published 
API 

Yes 

Y  /  N  /  NA 

6. 

Access  Virtual 
Spaces 

None  -  Done  by 
demonstration  with 
reference 

Yes 

Y  /  N  /  NA 

7. 

Join  conference 

-H.323  (Audio/Video) 
-T.120  (Data) 

Yes 

Y  /  N  /  NA 

8. 

Share 

applications 

ITU  T.  128 

Yes 

Y/N/NA 

9. 

Whiteboards 

T.126 

Yes 

Y  /  N  /  NA 

llil 

Audio 

ITUH.323/G.711 

Yes 

Y/N/NA 

11. 

Video 

H.323/H.261 

Yes 

Y/N/NA 

12. 

File  transfer 

ITU  T.  127  FTP,  http& 

XML 

Yes 

Y/N/NA 

13. 

Authentication, 

Encryption, 

Lockdown 

Authentication  by 
password  or  certificate 
(PKI),  Encryption  by  SSL 
or  VPN;  workstations  & 
servers  locked  down 
according  to  type 
accreditation  requirements 

Yes 

Y/N/NA 

IQ 

Usability 

Yes 

Y/N/NA 

15. 

Directory 

Services 

LDAP  V3 

Future 

Y/N/NA 

4,  Interoperability  Testing  Process 

The  testing  process  used  by  JITC  covers  each  functional  area  within  the  DCTS 
program.  Each  collaborative  function  within  DCTS  has  its  own  test  process  and  set  of 
criteria.  This  section  will  address  the  test  criteria  applicable  to  each  collaborative 
capability.  Each  criterion  consists  of  a  series  of  steps  evaluated  on  a  pass-fail  basis. 
a.  Coexistence 
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The  purpose  of  this  test  eriterion  is  to  verify  the  product  being  tested  will 
not  interfere  with  or  disrupt  existing  DCTS  functions.  This  test  applies  to  all  collaborative 
functions  except  Authentication/Encryption/Lockdown,  Usability,  or  Directory  Services. 

The  coexistence  test  is  initiated  with  a  fresh  Operating  System  (OS)  load 
and  with  no  special  configurations  for  the  product  being  tested  or  the  DCTS  system.  JITC 
will  first  evaluate  the  vendor’s  documentation  for  the  DOD  Common  Operating 
Environment  (COE)  compliance  (level  5).  This  is  the  minimum  level  for  DOD 
interoperability  compliance  and  ensures  that  “applications  appear  integrated  to  the 
user.”2i  Once  the  documentation  review  is  complete,  the  candidate  system  is  installed. 
Once  properly  installed,  the  candidate  system  is  checked  for  normal  operation.  The  next 
phase  of  this  test  calls  for  a  system  security  lockdown.  This  condition  remains  in  place 
for  the  duration  of  the  test.  At  this  point  the  vendor’s  licensing  requirements  are  checked 
to  make  sure  that  any  user  DOD  can  use  the  system  on  a  complaint  network  without 
having  to  exchange  license  information.  Easily,  the  product  must  successfully  complete 
operation  with  the  existing  DCTS  system. 

b.  Collaborator  Status 

This  criterion  evaluates  the  ability  of  a  candidate  system  to  display 
collaboration  status  to  other  involved  parties.  The  DOD  requires  collaborative  tools  to 
publish  the  logon  status  of  system  users  and  so  users  can  view  all  possible  users  listed  in 
the  Global  Discovery  Server  (GDS)  when  logged  on. 

To  start  this  test,  a  reference  user  is  created  on  the  GDS  and  establishes  on 
online  presence.  The  DCTS  global  discovery  client  or  Candidate’s  client  is  then  activated 
on  the  system  being  tested.  Once  launched  the  client  must  discover  the  presence  and 
awareness  of  the  reference  user.  To  set  up  the  final  test  of  this  criterion,  the  candidate 
system  must  pass  the  information  to  the  GDS.  Once  this  occurs,  the  collaboration  status 
of  the  reference  user  is  verified  on  the  client  system  within  the  DCTS. 

c.  Conference  Discovery 

In  this  criterion,  the  user  must  be  able  to  show  the  availability  and  location 
of  all  published  conferences  (also  called  meetings)  conforming  with  the  ITU  H.323/T.I20 
standards.  The  reference  or  location  may  be  in  the  form  of  an  Internet  Protocol  (IP) 
21  Deliverins  on  the  promise  of  ‘plus  and  play  \  Daniel  Verton,  Dec  6,  1999,  Federal  Computer  Week 
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address  or  a  Uniform  Resource  Locator  (URL).  Once  the  information  is  gathered,  it  must 
to  published  to  the  GDS.  Furthermore  the  system  must  allow  the  user  to  access 
information  about  published  meeting  schedules. 


This  test  is  initiated  once  a  reference  user  is  logged  in  to  DCTS  and  a 
conference  is  established  on  the  DCTS  conference  server.  As  in  the  previous  test,  the 
discovery  agent  is  launched  either  from  the  DCTS  or  candidate  client.  The  client  will 
attempt  to  discover  the  meeting  on  the  DCTS  Multipoint  Control  Unit  (MCU).  If  the 
client  is  hosting  the  meeting  then  the  information  about  it  must  be  published  on  the  GDS. 
Once  this  is  complete,  the  conference  is  verified  on  the  parent  DCTS  system. 

d.  Virtual  Space  Discovery 

The  purpose  of  this  criterion  is  for  the  candidate  to  poll  the  GDS  and  the 
occupants  of  virtual  spaces  so  the  results  can  be  published  to  end  users. 

The  test  is  started  once  the  reference  user  is  logged  on  and  publishes  an 
online  workspace.  The  discovery  agent  is  launched  on  the  candidate  system  and  is  used  to 
find  any  public  virtual  space  (including  occupants)  located  on  the  GDS.  If  the  system  is 
hosting  the  virtual  space  it  must  be  able  to  publish  the  appropriate  information  to  the 
GDS.  Once  these  parts  are  completed,  the  virtual  space  and  occupants  are  verified  from 
the  candidate  on  DCTS. 

e.  Text  Conference 

In  this  criterion  the  candidate  supports  text  based  conferences.  To  start  the 
test  a  reference  user  logs  in  to  DCTS  and  establishes  its  presence.  Once  logged  in  a  text 
based  message  exchange  is  coductded  with  single  DCTS  user.  If  successful  the  test  is 
expanded  so  the  candidate  must  conduct  a  text  conference  with  multiple  DCTS  users 
simultaneously  in  individual  sessions.  The  last  part  of  this  test  is  for  a  multiple  user  text 
conference  in  a  group  chat  environment. 

f  Virtual  Space  Access 

This  criterion  is  intended  to  determine  if  the  candidate  can  access  any 
virtual  space  that  exists  on  the  GDS  and  follows  the  requirement  to  discover  virtual 
spaces.  In  this  test,  there  is  a  provision  that  allows  a  system  to  use  an  alternate  virtual 


27 


space  access  method  if  it  is  not  an  integral  part  of  the  system  being  tested.  This  test  also 
looks  at  the  system’s  ability  to  host  a  virtual  space  and  grant  access  to  others 

The  test  is  started  once  the  DCTS  discovery  agent  or  candidate  client  is 
activated.  The  client  must  discover  a  public  virtual  space  on  the  GDS,  access  and  verify 
proper  virtual  space  operation  on  the  candidate  system.  Once  a  single  space  is  verified  the 
system  must  demonstrate  the  ability  to  access  multiple  virtual  spaces.  The  ability  to  host 

virtual  spaces  must  also  be  demonstrated  if  this  capability  exists  on  the  candidate  system. 
The  last  phase  of  this  criterion  testing  calls  for  a  test  of  these  capabilities  on  the  DCTS 
system. 

g.  Conference  Join 

Since  the  candidate  system  already  demonstrated  the  ability  to  discover 
conferences,  this  test  establishes  the  candidate  system’s  ability  to  join  them. 

The  test  is  started  once  a  reference  user  is  logged  in  to  DCTS,  a 
conference  is  established,  and  the  conference  is  joined  by  a  DCTS  client.  Then  the 
candidate  conference  client  or  DCTS  conference  client  is  launched  on  the  candidate 
system.  The  candidate  system  must  successfully  join  the  conference  and  operate  properly 
using  conference  functions  with  the  reference  user.  Once  the  candidate  demonstrates  the 
success  in  the  single  meeting  environment,  it  must  demonstrate  the  ability  to  exit  and 
reenter  meetings.  The  next  step  is  for  the  candidate  to  exit  the  meeting,  join  another,  and 
then  rejoin  the  original  meeting.  The  candidate  must  then  schedule  a  meeting  and  publish 
the  information  on  the  GDS.  Once  scheduled,  its  creation  is  verified  from  the  DCTS 
reference  user  and  the  candidate’s  conference  is  joined.  At  this  point  the  reference  user 
and  the  candidate  client  interact  to  verily  meeting  functionality.  The  last  step  is  for  the 
reference  user  to  exit  this  meeting,  join  another  meeting,  and  then  return  to  the  candidate 
conference. 

h.  Application  Sharing 

In  this  criterion,  the  candidate  system  is  evaluated  for  its  application 
sharing  capability  using  a  graphically  intensive  program. 

The  start  condition  exists  when  a  reference  user  joins  a  conference  on 
DCTS.  The  conferencing  client  is  activated  on  the  candidate  system  and  participates  with 
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the  reference  user  in  the  meeting.  Once  this  happens  the  application  sharing  functionality 
is  tested.  The  testing  process  looks  at  the  ability  of  the  candidate  system  to  handle  a 
graphically  intense  program,  the  ability  to  relinquish  control  of  the  application,  and  the 
ability  to  regain  control  of  the  application.  If  applicable,  the  next  part  looks  at  the  ability 
of  the  candidate  system  to  host  application  sharing  meetings.  The  system  is  required  to 
publish  the  conference  information  onto  the  GDS  and  allow  other  clients  to  discover  and 
join  the  meeting.  Once  joined,  the  meeting  functionality  to  verified  in  the  same  manner  as 
this  initial  application  sharing. 

L  Whiteboard 

This  section  evaluates  the  candidate  system’s  ability  to  join  a  whiteboard 
session  on  DOTS  and  interact  with  others. 

The  test  is  started  with  a  reference  user  logging  on  to  DOTS  and  joining  a 
meeting.  From  there,  a  conferencing  client  is  launched  on  the  candidate  system  and  joins 
the  reference  user  in  the  applicable  meeting.  The  whiteboard  functionality  is  tested  within 
the  meeting  by  viewing  and  modifying  a  still  image  with  other  users.  If  the  system  still 
hosts  meetings,  the  information  is  posted  to  the  GDS  and  the  candidate  launches  the 
conference.  The  session  is  checked  from  the  reference  user  on  DCTS. 

j.  Audio 

This  part  of  the  testing  checks  the  ability  of  a  candidate  system  to 
exchange  audio  information  between  users. 

As  with  other  tests,  a  reference  user  joins  a  DCTS  based  conference  and 
the  candidate  system  does  the  same.  Once  the  reference  and  candidate  user  are 
participating  in  the  meeting,  the  ability  to  conduct  a  point-to-point  audio  exchange  is 
conducted.  Next  the  system’s  ability  to  exchange  multi-point  audio  is  tested.  The  testing 
then  evaluates  to  the  candidate  system’s  ability  to  host  conferencing  with  an  audio.  As  in 
other  tests,  the  candidate  establishes  a  conference  and  is  joined  by  the  reference  user.  The 
point-to-point  and  multi-point  audio  exchange  capabilities  are  then  tested  while  being 
hosted  by  the  candidate  system. 

k.  Video 

In  this  criterion  the  candidate  system  is  tested  to  see  if  it  can  exchange 
video  with  other  users  on  DCTS. 
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The  reference  user  and  candidate  client  join  a  published  DCTS 
conference.  A  point-to-point  video  session  is  established  between  the  users  and  a  multi¬ 
point  session  subsequent  to  that.  Once  each  video  transfer  is  in  progress,  the  features  are 
tested  for  full  operational  capability.  After  this  is  complete  the  system’s  ability  to  host 
video  sessions  is  checked  similar  to  the  audio  test. 

I  File  Transfer 

This  criterion  investigates  the  candidate  system’s  ability  to  import  and 
export  documents  within  DCTS. 

A  reference  user  logs  on  to  a  published  DCTS  meeting  with  the  candidate 
client.  The  candidate  client  will  export  a  file  (document)  to  the  DCTS  virtual  space.  Once 
accomplished,  the  reference  user  activates  the  DCTS  discovery  client  to  import  the 
document  to  the  DCTS  machine.  Once  downloaded,  the  document  is  opened  to  see  if  it 
works  as  expected.  Next  the  DCTS  user  exports  a  file  to  the  virtual  space  and  is  imported 
by  the  candidate  client.  The  downloaded  file  is  then  checked  for  the  appropriate 
functionality. 

m.  Authentication,  Encryption,  Lockdown 

This  criterion  focuses  on  functionality  that  will  appear  transparent  to  the 
user  after  initial  connections  are  established.  The  goal  of  this  test  is  to  verily  that  systems 
used  in  a  Command  and  Control  Environment  are  interoperable  with  DCTS  security 
criteria.  The  specific  requirements  are  listed  in  the  DCTS  SSAA  Version  1.1  (30  Jan 
2002)  and  DOD  Directive  5200.28. 

The  test  is  started  with  a  reference  user  logged  on  to  DCTS.  The  first  test 
checks  to  see  that  proper  authentication  with  a  user  name  and  password  occurs  before  the 
candidate’s  client  is  allowed  access  to  spaces,  collaborators,  or  conferences.  If  successful, 
the  next  step  verifies  the  end-to-end  encryption  using  the  Secure  Socket  Layer  (SSL), 
Virtual  Private  Network  (VPN),  or  other  equivalent  technology.  Lastly,  the  test  will 
evaluate  the  ability  of  the  candidate  workstations  to  be  locked  as  determined  by  the 
appropriate  accreditation  requirements. 

n.  Usability,  Stability,  Performance 
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The  usability  testing  items  are  still  being  developed  however  the  goal  of 
these  tests  is  to  verify  that  candidate  systems  can  operate  over  time  with  an  acceptable 
level  of  reliability,  or  “up  time”. 

The  test  starts  with  a  reference  user  inviting  the  candidate  to  a  DCTS 
conference  room.  The  candidate  selects  the  conference  room  link  and  enters  the  meeting. 
At  this  point  the  candidate  enables  text  chat,  whiteboard,  application  sharing,  and  file 
sharing  for  30  minutes.  The  candidate  succeeds  if  the  conference  is  held  successfully  and 
can  be  closed  when  finished.  This  test  is  repeated  two  additional  times  with  success 
determined  based  on  the  availability  and  proper  operation  of  the  candidate  system. 

o.  Directory  Services 

Currently  this  capability  is  not  tested  because  it  does  not  exist  for  the 
DOD  yet.  Although  the  capability  is  does  not  currently  exist,  this  capability  is  identified 
as  a  future  DOD  requirement  for  DCTS  certification. 

5.  Post  Testing  Phase 

With  testing  complete  JITC  will  now  take  one  of  two  actions.  The  first  possible 
action  results  when  the  product  successfully  passes  the  certification  tests.  JITC  will 
forward  the  results  to  CMO  who  approves  the  logo  agreement.  The  logo  agreement 
establishes  the  label  the  product  may  carry  as  appropriate  to  the  testing  accomplished. 
There  are  three  logos  (or  approved  language  sets  and  Table  7  lists  the  three  label  types. 


Table  7.  DCTS  Logo  Requirements 


Approved  Language 

Requirements 

DoD  Certified  Interoperable  Collaboration 

System  -  v.2  Phase  1 

Pass  all  procedures 

DoD  Certified  Interoperable  Collaboration 

Component  -  v.2  Phase  1 

Pass  all  procedures  for  criteria  1,  2,  3,  4, 

13,  and  14.  Pass  all  procedures  for  one  or 

more  of  criteria  5,  6,  7,  8,  9,  10 

DoD  Certified  Interoperable  Collaboration 

Enhancement  -  v.2  Phase  1 

Pass  all  procedures  for  criteria  1,  2,  3,  4, 

13,  and  14  +  CMO  certification  as  a 

collaboration  enhancement 
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A  slightly  more  complicated  process  follows  when  the  product  fails  the 
certification  test  process.  If  the  product  fails,  the  vendor  is  notified  and  has  the  option  to 
reclama  to  CMO.  This  is  essentially  an  appeal  to  the  next  level  in  the  chain  of  command. 
If  the  CMO  denies  the  reclama,  no  logo  is  awarded  for  the  vendor’s  product.  If  the 
reclama  is  approved  by  the  CMO  product  retesting  will  occur.  The  important  question 
that  arises  at  this  point  is  whether  the  retest  will  occur  at  no  cost  to  the  vendor.  If  it  is 
determined  that  a  no-cost  retest  will  occur,  JITC  schedules  the  test  and  notifies  and 
vendor  and  CMO.  If  the  vendor  will  pay  for  the  retest,  then  a  complete  resubmission  of 
the  testing  application  is  required. 

C.  IMPLICATIONS  FOR  A  TRANSFORMED  NETWORK  OPERATIONS 

MODEL 

The  implication  for  a  transformed  network  operations  model  is  straightforward. 
Any  collaborative  tool  set  that  will  be  used  on  DOD  networks  must  be  tested  for 
interoperability  with  DCTS.  If  the  solution  for  the  new  network  operations  model 
includes  collaborative  tools,  it  must  undergo  interoperability  testing.  Once  a  product 
passes  the  interoperability  testing,  it  is  allowed  to  be  installed  on  the  appropriate  level  of 
DOD  information  system. 

The  interoperability  testing  requirement  creates  additional  cost  for  the  any 
collaborative  product.  The  vendor  must  pay  the  required  fees  to  have  the  testing 
accomplished  and  those  costs  are  likely  to  be  passed  on  to  the  government  customer. 
Although  the  certification  costs  are  nonrecurring,  they  should  be  accounted  for  during 
initial  budget  estimation. 
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IV.  ARCHITECTURE  FOR  TRANSFORMED  NETWORK 

OPERATIONS 

A,  TRANSFORMED  NETWORK  OPERATIONS  VISION 

1,  Goals  and  Objectives 

FORCEnet  is  the  enabler  for  the  US  Navy’s  strategie  initiative,  Seapower  21. 
FORCEnet  will  ereate  a  fully  networked  foree  through  existing  initiatives  and  programs 
to  support  assured  aeeess,  power  projeetion,  and  expeditionary  maneuver  warfare22.  It 
will  eonneet  taetieal  and  non-taetieal  information  networks  in  a  streamlined  paekage  as 
opposed  to  the  stove  piped  information  networks  of  today.  This  paper  seeks  to  support 
FORCEnet  by  ereating  a  model  for  future  network  operations.  The  new  network 
operations  model  will  apply  existing  eoneepts  to  the  network  operations  domain. 

2,  Core  Capabilities 

a.  Provide  Shipboard  Network  Operations  Capability 

The  primary  goal  of  this  researeh  is  to  provide  ships  with  a  eapability  to 
perform  network  operations  at  sea.  The  existing  eapability  is  very  limited  for  ships  to 
manage  their  internal  EANs  and  there  is  no  eapability  onboard  ship  to  aeeomplish 
network  operations  for  external  networks.  Providing  this  eapability  to  fleet  assets 
inereases  the  possibility  that  FORCEnet  will  “transform  situational  awareness,  aeeelerate 
speed  of  deeision,  and  allow  [the  Navy]  to  greatly  distribute  eombat  power.”23 

Providing  these  eapabilities  onboard  ships  removes  a  major  single  point  of 
failure  in  the  fleet  network  arehiteeture.  Fleet  assets  are  eompletely  reliant  on  the  regional 
NOCs  for  network  eonneetivity  beeause  the  regional  NOCs  are  the  eentral  hub  for 
network  information  flow  for  the  fleet  (for  non-taetieal  networks).  The  NOCs  are 
responsible  for  all  network  management  funetions  leaving  fleet  units  in  a  passive  role  in 
maintaining  network  eonneetivity.  Problems  as  experieneed  by  fleet  assets  are  reported  to 
the  NOC  but  after  that  point  the  ship  plays  little  to  no  role  in  fixing  problems. 

This  eauses  two  possible  eonsequenees.  First,  although  eertain 
redundaneies  exist,  a  failure  at  the  NOC  may  potentially  disrupt  fleet  network 

22  FORCEnet  IOC  Brief,  CNO  N7  (Warfare  Requirements  and  Programs),  22  March  2002 

23  http://www.chinfo.navy.miFnavpalib/cno/proceedings.html,  Jan  2004 
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connectivity.  As  information  networks  become  essential  to  combat  operations,  failures 
become  increasingly  critieal  to  mission  suecess.  Seeond,  due  to  the  nature  of  the  NOC’S 
mission  as  a  supporting  entity,  they  are  not  necessarily  aware  of  immediate  operational 
requirements.  Fleet  assets  can  provide  invaluable  perspeetive  when  correeting  outages  or 
alloeating  resources  sinee  are  intrieately  involved  with  operations  and  exercises.  With 
fleet  involvement,  the  effects  of  problems  ean  be  minimized  and  planning  efforts  ean  be 
maximized. 

b.  Support  Dynamic  and  Distributed  Force 

Sinee  its  inception,  the  Navy  has  operated  overseas.  What  has  changed 
over  time  is  the  nature  of  how  ships  operate  together.  Today’s  fleet  assets  may  operate 
hundreds  of  miles  from  one  another  but  still  need  to  maintain  data  and  voice 
eommunications  to  aeeomplish  a  mission.  The  Navy  eontinues  to  evolve  the  way  forees 
are  employed  but  the  need  to  maintain  the  flow  of  information  to  deeision-makers 
remains  eritical. 

The  fleet  network  is  used  in  a  mueh  more  complex  environment  than  a 
typical  shore  based  network.  In  fact,  the  CNO’S  Sea  Power  21  strategy  calls  for  the  fleet 
to  be  even  more  flexible  and  responsive  than  today  standards24.  The  level  of  complexity 
continues  to  increase  with  the  introduetion  of  remotely  operated  and  fully  networked 
unmanned  vehicles  into  the  fleet.  With  this  in  mind,  personnel  are  required  to  address 
many  additional  network  considerations  beyond  that  of  the  typieal  shore  based  network. 

Unlike  networks  residing  in  faeilities  that  are  geographically  fixed,  fleet 
networks  are  located  on  highly  mobile  platforms.  Ships  and  submarines  travel  around  the 
world  supporting  a  wide  range  of  operations.  Fleet  assets  may  move  between  satellite 
coverage  areas  or  between  fleet  NOC  areas  of  responsibility.  Depending  on  whether  a 
eommand  is  operating  overseas  or  in  the  United  States,  at  sea  or  in-port,  the  network 
eonnection  may  be  through  a  land  line  or  satellite  eonnection.  Different  types  of  fleet 
eommands  require  different  network  serviees.  For  example,  a  command  ship  uses 
significantly  more  bandwidth  and  network  services  than  a  destroyer  beeause  of  a  greater 
need  for  eommunications.  The  transformed  network  operation  model  must  be  able  to 

24  http://www.chinfo.navy.miFnavpalib/cno/clark-guidance2004.html,  Jan  2004 
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manage  the  different  conneetion  types  and  the  potential  for  status  ehanges  for  individual 
assets  and  groups  of  assets  regardless  of  geographie  location. 

c.  Collaborative 

Collaboration  is  simply  defined  as  “the  act  of  working  together”25  and  is 
not  a  new  concept.  Electronic  collaboration  emerged  in  the  last  decade  as  computer 
networks  proliferated  around  the  world.  In  1995,  the  World  Wide  Web  Consortium 
(W3C)  held  a  workshop  to  explore  collaboration  protocols  and  since  then  collaboration 
technologies  continued  to  expand  and  gained  increased  value  across  a  variety  of 
organizations. 

The  goal  of  this  paper  is  to  introduce  groupware,  or  collaborative  support 
technologies26,  into  the  transformed  network  operations  model  because  of  the  many 
benefits  offered.  Adding  collaboration  to  the  network  operations  process  may  be  the 
single  biggest  improvement  compared  with  other  individual  technologies.  There  is  much 
more  knowledge  in  a  collaborative  group  than  any  single  person  possesses.  The 
individuals  involved  gain  tremendous  knowledge  by  interacting  with  other  members  of 
the  group.  This  knowledge  translates  into  better  individual  performance  in  the  future.  The 
group  as  a  whole  benefits  because  collaborative  tools  allow  for  increased  innovation  in 
terms  of  problem  solving  because  of  the  communication  among  group  members.  As  a 
group  shares  information  and  seeks  solutions,  a  wider  variety  of  possibilities  emerges  as  a 
result  of  collaboration.  Collaboration  also  allows  the  decision  process  to  be  evaluated  by 
all  the  involved  group  members27. 

In  the  context  of  fleet  network  operations,  collaboration  brings  multiple 
benefits.  Collaboration  allows  group  members  to  work  towards  a  single  objective  (ex., 
during  troubleshooting)  to  avoid  “re-inventing  the  wheel”28.  This  results  in  reducing  the 
time  needed  for  individual  issues  because  communication  is  increased29.  Group 
efficiency  is  also  positively  impacted  because  of  the  potential  for  synchronous  and 

25  http://www.hyperdictionary.coin/dictionary/collaboration,  Dec  2003 

26  Decision  Support  Systems  in  the  2D‘  Century,  George  M.  Marakas,  Prentice  Hall,  1999 

27  Decision  Support  Systems  in  the  2D‘  Century,  George  M.  Marakas,  Prentice  Hall,  1999 

28  http://www.e-govemment.govt.nz/docs/govis2002-procurement/chapterl0.html,  Jan  2004 

29  http://www.kjmassoc.com/e_onlinecollaboration.asp.  Jan  2004 
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asynchronous  operations.  As  an  example,  asynehronous  eollaboration  can  allow 
individuals  to  accomplish  routine  maintenanee  with  proeedures  posted  to  a  common  file 
space.  Synchronous  collaboration  facilitates  planning  for  operations  since  all  participants 
can  discuss  the  relevant  issues  at  one  time  instead  of  requiring  additional  time  for 
feedback  or  reporting.  A  major  benefit  for  the  Navy  is  the  ability  of  electronic 
collaborative  tools  to  remove  geographic  barriers30  since  partieipants  may  be  loeated 
anywhere  in  the  world.  The  intent  of  this  paper  is  not  to  examine  the  benefits  of 
collaboration.  Instead,  it  is  assumed  that  collaboration  adds  great  benefits  to  the 
efficieney  and  effeetiveness  of  group  proeesses  based  on  existing  researeh.  The  intent 
here  is  to  ereate  a  eollaborative  model  applicable  to  the  network  operations  environment 
and  is  discussed  in  the  next  seetion. 

d.  “Reach  Back” 

The  reaeh  back  capability  refers  to  the  ability  for  deployed  forces  to 
contact  the  appropriate  support  activities  through  long-haul  network  connectivity.  This 
capability  currently  exists  in  a  limited  capacity  through  naval  message  traffic,  radio¬ 
telephone  (R/T)  circuits,  telephone,  and  email. 

Fleet  assets  used  radio  message  traffic  to  communicate  with  distant 
commands  for  decades.  In  terms  of  eorrespondence,  it  is  still  the  only  “offieial”  method 
to  communicate  with  other  eommands  despite  being  based  on  very  old  technology. 
Although  still  used,  it  is  ill  equipped  to  effeetively  function  in  a  network  operations 
environment.  The  information  systems  used  to  send  this  information  have  improved  over 
time  but  sending  messages  is  slow,  cumbersome,  and  often  ineurs  significant  message 
backlogs  due  to  system  capaeity  limitations.  Sending  these  messages  is  also  manpower 
intensive  compared  with  other  means  (ex.,  email).  Radio  message  traffic  is  simply 
inadequate  for  the  network  operations  environment. 

R/T  cireuits,  or  voice  circuits,  are  commonly  used  in  operational 
environments.  These  allow  operators  to  easily  pick  up  a  handset,  press  a  button,  and 
synchronously  communicate  with  one  or  more  entities  on  the  cireuit.  Ships  and  aircraft 
have  communications  equipment  limitations  beeause  a  limited  amount  of  transmitters  and 

30  http://www.ltscotland.org.uk/connectingcommutiities/benefits_collaboratioti_on_the_Net.asp,  Jan 
2004 
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receivers  are  available  in  comparison  to  the  many  tactical  circuits  that  must  be  monitored. 
Dedicating  a  circuit  to  network  operations  would  reduce  the  capability  for  another 
mission  area.  A  second  reason  this  is  not  appropriate  for  network  operations  is  the  lack  of 
ability  to  maintain  a  record  of  events.  It  is  possible  to  record  these  circuits,  but  retrieving 
and  storing  the  information  so  it  may  be  used  later  is  very  difficult  to  accomplish  with 
existing  systems.  Another  problem  with  voice  circuits  is  the  challenge  to  operators  in 
describing  problems  and  situations.  Difficult  issues  can  take  a  long  time  to  resolve 
because  of  the  limited  ability  of  users  to  provide  situational  awareness  to  the  support 
activities.  This  causes  a  needless  increase  in  the  amount  of  time  required  to  fix  problems. 
Efforts  should  be  directed  more  towards  correcting  problems  rather  than  determining 
them.  Lastly,  acquiring  additional  voice  communications  equipment  to  increase  the  reach 
back  capability  does  not  provide  enough  return  on  investment.  The  conclusion  to  be 
drawn  is  that  voice  circuits  as  currently  implemented  aboard  fleet  units  are  inappropriate 
in  network  operations.  Telephones  are  another  tool  that  the  fleet  uses  to  communicate 
with  support  activities  either  through  land  lines  or  satellites.  The  telephone  has 
comparable  problems  to  voice  circuits  so  they  will  not  be  discussed  further. 

Electronic  mail  (email)  is  the  last  type  of  capability  applicable  in  this 
discussion.  While  still  considered  an  unofficial  means  of  communication,  email  use  has 
rapidly  expanded  in  the  Navy  since  the  IT21  program  was  initiated  in  the  early  1990s. 
Email  is  fast,  can  be  sent  to  multiple  recipients  at  one  time,  provides  limited  file  sharing 
capabilities  (through  attachments),  and  produces  a  record  of  communication  between 
parties3i  32.  Email  does  have  certain  disadvantages  though.  Email  only  allows 
asynchronous  communication,  meaning  that  the  recipient  won’t  be  able  to  communicate 
in  real-time.  There  will  always  be  a  delay  between  the  time  of  the  original  transmission 
and  receipt  of  a  response.  The  biggest  disadvantage  may  be  that  communicating  among  a 
group  of  people  is  cumbersome.  It  was  intended  to  be  a  “one-to-one  medium”  and 
requires  active  participation  by  users33.  As  an  example,  imagine  that  an  email  requiring 
reply  is  sent  to  a  group  of  people.  Each  recipient  will  receive  the  message  and  send  a 

3 lhttp://www.buffalolib.org/ComputerTraiiiing/training. email.pros.html,  Jan  04 

32  HTTP:/AVWW.HOMEBUSINESSMANUAL.COM.AU/TECHNOLOGY/EMAIL.HTML,  JAN  04 

33  http://klingon.cs.iupui.edU/~aharris/mmcc/mod8/abip23.html#@1123,  Jan  04 
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response  to  the  original  sender  and  possibly  the  entire  group.  The  original  sender  must 
then  read  each  the  response  to  gather  the  applicable  feedback.  In  a  large  group,  this  takes 
a  tremendous  amount  of  time  and  can  be  made  worse  if  all  users  see  all  replies.  Lastly, 
email  is  not  the  most  reliable  means  to  communicate.  There  is  no  guarantee  that  an  email 
will  be  received  and  the  sender  may  not  be  aware  that  a  message  was  lost. 

3,  Technologies 

a.  COTS 

Commercial-Off-The-Shelf  (COTS)  may  also  be  called  a  Non- 
Developmental  Item  (NDI)  within  the  DOD.  A  COTS-based  approach  is  used  to  acquire 
a  technology  or  system  that  already  exists  in  the  marketplace,  thus  reducing  the  need  to 
develop  a  product  from  scratch  saving  money  and  deployment  time  and  accomplishing 
performance  requirements.  To  successfully  apply  the  COTS  principle,  organizations  must 
consider  the  context  where  the  system  will  be  used,  evaluate  the  existing  marketplace,  the 
system  architecture,  design,  and  other  considerations34. 

There  are  a  couple  of  benefits  to  this  type  of  effort  for  network 
operations.  First,  there  is  a  great  cost  savings  potential  when  purchasing  a  product  that 
already  exists.  The  research,  development,  testing,  and  evaluation  (RDT&E)  of  a  product 
is  already  accomplished  for  a  given  set  of  capabilities  saving  the  customer  tremendous 
amount  of  time  and  money.  Since  information  networks  operate  on  common  protocols 
and  standards,  the  performance  requirements  can  also  be  met  for  the  network  operations 
model.  Additional  COTS  benefits  include  increased  system  capabilities,  greater  system 
quality,  and  reduced  downstream  maintenance. 35 

b.  Network  Management  Suite 

The  core  functions  for  fleet  network  operations  reside  in  the  network 
management  suite.  This  paper  will  evaluate  existing  network  management  tools  to 
establish  the  baseline  set  of  capabilities  to  be  included  for  use  in  the  fleet.  The  primary 
software  bundles  that  will  be  examined  are  “What’s  Up  Gold”  (WUG)  from  Ipswitch  and 
“Solarwinds  Engineer  Edition”  (SER)  from  Solarwinds.  These  software  packages  were 
selected  for  evaluation  because  they  are  both  being  already  being  used  by  the  Navy  in 

34  http://www.sei.cmu.edu/cbs/overview.html.  Feb  04 

35  http://www.sei.cmu.edu/cbs/lessons/program-management/rec3.htm,  Feb  04 
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different  capacities.  Secondly,  the  manner  in  which  these  tools  accomplish  network 
management  is  accomplished  is  sufficiently  different  to  effectively  compare  and  contrast 
software  functions.  The  use  of  these  software  tools  does  not  serve  to  endorse  either 
product.  The  goal  of  examining  these  software  packages  is  to  create  a  generic  model  for  a 
transformed  fleet  network  operations  model.  Once  completed  the  transformed  network 
operations  model  will  provide  “data  gathering,  dynamic  topological  awareness,  advanced 
analytics”36 

The  first  important  consideration  for  a  network  management  suite  is  that  it 
must  be  able  to  manage  common  network  standards  like  SNMP.  Using  a  standards  based 
approach  for  network  management  software  allows  the  various  network  management 
nodes  to  share  the  same  relevant  information  from  a  variety  of  hardware  platforms. 
Proprietary  solutions  that  only  handle  a  single  product  line  are  not  suited  to  the  needs  of 
the  Navy.  Since  the  Navy  does  not  use  a  single  vendor’s  hardware,  these  products  add 
needless  expense  and  provide  very  little  gain. 

Any  network  management  suite  must  have  the  ability  to  conduct  network 
discovery  or  mapping.  This  capability  allows  the  software  to  locate  the  devices  that  are 
present  on  the  network.  Once  the  software  recognizes  the  devices  on  the  network,  it  can 
then  provide  information  about  device  performance.  WUG  and  SLR  use  two  different 
approaches  for  this  function.  WUG  uses  a  windows  based  discovery  wizard  that  takes  the 
user  through  the  discovery.  SLR  presents  the  user  with  a  window  that  resembles  a 
common  web  browser.  Although  both  packages  use  familiar  graphic-user-interfaces 
(GUI)  common  in  other  applications,  the  final  display  of  these  packages  differ 
significantly.  The  WUG  output  is  a  color  picture  that  shows  nodes  and  their  connections 
while  the  SLR  output  is  a  window  with  text  based  information.  In  both  cases,  the  tools 
use  color  variations  to  present  a  quick  information  summary  for  the  user.  Both  packages 
require  the  operator  to  enter  certain  information  such  as  the  IP  address  range  for  a  given 
subnet.  This  capability  allows  administrators  to  easily  recognize  what  devices  are 
connected  on  the  network  and  is  essential  because  network  monitoring  cannot  occur  until 
this  is  done.  The  ease  of  discovery  in  both  packages  allows  administrators  to  rapidly 

36  Network  Management  Tools  and  Trends,  Mike  Jude,  Business  Communications  Review,  May  2002 
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adjust  the  software  suite  to  handle  the  dynamic  fleet  network  environment.  Additionally, 
the  WUG  package  allows  the  user  to  select  the  type  of  service  to  seek  in  addition  to  IP 
addresses.  The  specific  function  allows  administrators  to  tailor  the  network  by  traffic  type 
monitoring  as  needed. 

The  next  capability  to  discuss  is  network  monitoring.  This  is  the  most 
important  function  required  in  any  network  operations  center.  This  capability  provides  a 
view  of  network  status  so  an  operator  can  determine  the  health  of  the  network  as  a  whole 
or  for  individual  nodes.  The  primary  method  of  SLR  is  through  a  multicolor  window 
containing  tabular  information  that  provides  network  performance  information.  Each 
device  is  listed  with  the  respective  status  and  associated  graphic.  SLR  can  also  display 
each  interface  as  separate  node.  For  example,  this  proves  helpful  to  network  managers 
when  devices  have  more  than  one  IP  address  because  the  software  can  monitor  each 
address  separately.  As  conditions  change,  the  textual  information  is  updated  and  the 
graphic  is  changed  to  indicate  the  appropriate  status.  The  WUG  monitor  solution  is  very 
different  in  that  it  provides  a  graphic  for  a  particular  network  device  to  indicate  status. 
The  graphic  is  augmented  with  text  alerts  located  at  the  bottom  of  the  window.  The  WUG 
network  map  shows  nodes  and  connections  along  in  color  to  show  status.  As  events 
occur,  the  WUG  software  updates  the  color  of  the  graphic  and  the  text-based  data  as 
appropriate  to  indicate  status.  For  example,  a  node  that  loses  connectivity  will  change 
from  a  green  status  to  red  indicating  a  major  event.  The  goal  is  the  same  for  each  product 
even  though  the  implementations  are  dissimilar.  In  both  cases,  the  information  generated 
by  the  software  allows  the  network  administrator  to  quickly  determine  the  status  of  the 
network  and  its  devices.  It  is  obvious  why  this  capability  is  vital  to  the  network 
operations  center.  Users  must  have  the  ability  to  rapidly  determine  network  status  to 
effectively  manage  the  situation.  Any  solution  implemented  in  a  transformed  network 
operations  model  must  be  reasonably  intuitive  to  NOC  personnel  so  network  performance 
can  be  properly  and  easily  identified.  The  user  should  not  have  to  conduct  extensive 
searches  through  multiple  windows  to  establish  the  overall  performance  of  the  network. 
Since  the  displays  that  present  the  overall  network  situation  are  typically  high-level,  the 
software  must  be  capable  of  delivering  the  detailed  information  to  users  in  addition  to  the 
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rapid  overall  status  presentation.  This  ability  provides  NOC  personnel  to  correctly 
determine  the  cause  of  problems  or  identify  symptoms  of  impending  problems. 

Information  capacity37  or  information  throughput  monitoring  is  the  next 
function  that  must  be  included  within  the  network  operations  model.  The  term  is  often 
confused  with  bandwidth  monitoring  in  the  context  of  network  operations  because 
according  to  Hartley’s  Law,  information  capacity  is  a  function  of  bandwidth  and 
transmission  time. 38  The  important  concept  here  is  that  information  flow  between  nodes 
is  measured  and  compared  with  the  total  capacity  for  a  communications  channel.  This  is 
an  important  consideration  for  network  administrators  because  it  is  the  foundation  for 
data  throughput  between  nodes  in  a  network.  There  is  a  finite  amount  of  information 
capacity  available  to  the  fleet  and  is  likely  to  remain  that  way  in  the  future.  Historical 
trends  suggest  that  as  bandwidth  availability  has  increased,  so  has  the  number  of 
applications  requiring  a  piece  of  it.39  Since  bandwidth  is  a  finite  resource,  its  allocation  to 
fleet  units  must  be  accomplished  according  to  operational  requirements  so  that  the 
appropriate  capacity  exists  at  all  points.  Once  allocated,  network  operation  centers  use 
monitoring  tools  to  determine  the  utilization  of  the  various  fleet  connections.  What’s  Up 
Gold  and  Solarwinds  both  include  tools  that  allow  network  administrators  to  monitor 
information  capacity  although  the  implementations  are  very  different.  The  WUG  tool  is 
named  Throughput  Tool  and  allows  users  to  test  the  data  speed  for  a  network  connection 
in  bits  per  second.  To  determine  the  data  speed,  the  user  must  manually  select  the  Net 
Tools  window  containing  numerous  functions  organized  by  individual  tabs.  The  software 
conducts  the  test  by  sending  a  number  of  data  packets  across  the  chosen  connection.  The 
user  may  adjust  the  number  of  packets  sent,  the  timeout,  packet  size,  and  the  time  the 
system  will  wait  for  a  response.  At  any  point  the  user  can  stop  the  test  with  a  click  of  a 
button.  The  SLR  function  is  called  the  Bandwidth  Monitor  and  displays  data  throughput 
in  bits  per  second  (bps).  The  basic  presentation  is  a  tabular  view  of  each  node  including 
each  interface  and  the  respective  throughput.  The  left  side  of  the  window  provides  point 

37  Electronic  Communication  Systems  Fundamental  through  Advanced  4*  Ed,  Wayne  Tomasi,  2001, 
Prentice  Flail 

38  Electronic  Communication  Systems  Fundamental  through  Advanced  4*  Ed,  Wayne  Tomasi,  2001, 
Prentice  Flail 

39  IS4920  Intro  to  C4I  Systems,  Prof  Rex  Buddenberg 
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and  click  access  to  a  variety  of  eharts  and  graphs  related  to  information  capaeity 
ineluding  network  lateney,  packet  loss,  utilization  rates,  and  packet  transfers  while 
presenting  the  information  in  its  own  panel.  The  SLR  software  goes  beyond  this  basic 
functionality  to  monitor  information  capacity  using  a  tool  called  the  “Bandwidth  Gauge”. 
Throughput  information  (bps)  information  for  transmit  and  reeeive  is  displayed  in  a 
gauge  resembling  a  car  speedometer  and  shows  real  time  performanee  levels  for 
individual  nodes.  The  major  differenee  between  the  two  software  packages  is  that  WUG 
software  is  intended  for  one-time  throughput  tests  where  the  SLR  version  can  monitor  the 
status  continuously  while  the  software  is  running  is  selected.  Sinee  information  capacity 
is  important  in  the  fleet  network  environment,  the  network  operations  model  must  be  able 
to  perform  regular  monitoring  of  information  eapacity. 

An  alert  function  is  the  next  capability  that  should  be  included  in  the 
network  operations  model.  An  alert  is  a  “piece  of  triggered  information”  that  holds 
information  about  a  device,  contact  method,  and  other  conditions  associated  with  network 
performanee  events.40  Alerts  provide  network  administrators  an  automated  method 
become  aware  of  signifieant  network  events.  This  reduces  the  time  required  to  fix 
problems  sinee  the  user  doesn’t  have  to  spend  time  reviewing  historical  logs  or  observing 
performanee  parameters  trying  to  discover  them.  Onee  generated  by  NOC  personnel  and 
entered  into  the  system,  event  alerts  automatieally  inform  the  neeessary  person(s)  of  a 
problem,  leading  to  more  efficient  problem  solving.  Both  WUG  and  SLR  offer  options 
for  a  variety  of  performanee  alerts.  Solarwinds  provides  event  alerting  through  electronic 
mail  or  paging.  It  can  alert  users  to  events  related  to  network  latency,  high  percentage 
utilization,  status  changes  for  individual  interfaees,  abnormal  error  numbers  (totals),  and 
other  network  performance  properties.  The  What’s  Up  Gold  alert  functions  provide  a 
larger  range  of  notification  types.  In  addition  to  paging  and  email,  it  generates  audible 
alerts  at  the  console,  beeper  notification,  program  execution,  telephone  notification 
through  pre-recorded  messages,  popup  messages  for  Windows  NT  systems,  recurring 
alerts,  and  grouped  alerts  where  more  than  one  alert  type  can  be  used  for  a  particular 
event.  Both  software  alert  systems  allow  the  user  to  edit  the  alerts  presenting 
administrators  with  the  ability  to  tailor  network  monitoring  as  needed.  This  functionality 
40  What’s  Up  Gold  User’s  Guide,  software  version  8 
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gives  increased  flexibility  to  network  administrators  so  they  can  properly  establish  key 
performance  parameters  in  the  current  operating  environment.  Furthermore,  the  ability 
for  network  management  software  to  alert  users  reduces  the  response  time  for  significant 
events  that  can  affect  network  performance. 

The  capabilities  discussed  to  this  point  are  related  to  real-time  network 
performance.  While  real-time  monitoring  is  the  primary  element  to  network  operations, 
the  story  of  network  performance  does  not  end  with  a  “green”  status  indication.  Network 
administrators  must  follow  up  real-time  monitoring  efforts  with  periodic  reviews  of 
performance  logs  and  reports.  These  reports  are  used  to  establish  historical  system 
performance,  trends,  and  also  contribute  to  increased  network  security.  There  are 
numerous  advantages  to  reviewing  logged  information.  The  information  can  be  looked  at 
with  an  aggregate  system  view  rather  than  focusing  on  a  single  piece  of  equipment.  One 
report  can  contain  information  from  “dozens  of  sensors”  that  is  more  convenient  than 
individual  devices  reports  would  be^i.  Analyzing  significant  network  events  viewed  by 
multiple  devices  becomes  easier  as  well.  As  an  example,  a  status  indicator  may  show  an 
interface  “up”  while  a  log  may  report  that  no  traffic  is  passing  through  that  connection. 
This  may  indicate  that  a  configuration  was  changed  without  the  administrator’s 
knowledge.  Analyzing  logs  also  bolsters  the  security  of  the  network  because  it  allows  the 
user  to  see  unusual  traffic  patterns,  like  unauthorized  access  requests  for  example.  The 
information  may  also  be  presented  in  the  form  of  a  graph  giving  the  user  an  instant  feel 
for  the  historical  performance  trends.  Regardless  of  the  specific  form  used,  the  network 
administrator  gains  considerable  insight  by  reviewing  the  logs  and  reports  not  provided 
through  normal  monitoring  windows.  Both  Whaf  s  Up  Gold  and  Solarwinds  includes 
robust  capabilities  in  this  area  suggesting  that  current  technology  is  more  than  adequate 
to  provide  useful  audit  information.  Although  not  a  new  technology  or  method,  logs  and 
reports  must  be  part  of  the  transformed  network  operations  model  because  of  the 
tremendous  benefits  to  network  managers. 

Used  earlier  as  an  example,  the  transformed  network  operations  model 
should  include  Simple  Network  Management  Protocol  (SNMP)  based  capabilities.  SNMP 

41  Inside  Network  Perimeter  Seeurity,  Stephen  Northeutt  et  al,  2003,  New  Riders  Publishing 
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has  emerged  as  the  model  for  network  management  beeause  it  ean  be  implemented  with 
little  eoding  and  agents  can  be  easily  built  adding  increased  functionality42.  It  is  a 
standard  but  it  more  importantly  defines  a  methodology  for  effective  network 
management. 

SNMP  is  used  by  many  platforms  to  gather  performance  information  for 
information  networks  because  it  is  part  of  the  TCP/IP  suiters  and  provides  remote 
management  functions  easing  the  burden  for  network  managers.  SNMP  entities  use  some 
basic  commands  (read,  write,  and  trap)  and  Management  Information  Bases  (MIB)  to 
establish  network  performance  information44.  The  SNMP  entities  perform  certain  tasks 
and  exchange  messages  about  network  performance  in  order  to  build  the  picture  for 
network  performance.  The  SNMP  Manager  entity  resides  in  an  application  and  generates 
requests  for  information.  Once  the  Manager  sends  a  request,  the  SNMP  Agent  will 
process  the  request,  gather  the  information  (trap),  and  reply  to  the  manager.  SNMP 
Agents  also  respond  to  network  events  if  the  user  has  created  a  notification  process. 
Another  way  for  the  Manager  to  receive  information  is  through  automatic  notification  by 
an  SNMP  Agent  about  a  network  event.  When  an  Agent  observes  a  significant  network 
event,  it  sends  an  event  report  to  the  Manager  for  processing.  The  manager  then  sends  a 
response  to  the  Agent  since  SNMP  incorporates  a  two  message  reporting  system.  SNMP 
also  facilitates  the  management  of  multi-domain  network  environments  since  entities  may 
take  on  a  “dual-role”  where  they  act  as  both  Managers  and  Agents.  The  dual-role  entity  is 
also  known  as  the  intermediate  or  proxy  manager  and  is  often  used  when  a  large  domain 
has  sub-domains  or  sub-networks.  In  this  case,  the  high  level  manager  sends  requests  to 
the  dual-role  entity,  which  receives  the  request  and  transforms  it  into  a  request  for  the 
appropriate  sub-network  Agent.  The  events  that  the  network  administrator  can  monitor 
are  vast  with  SNMP.  The  SNMP  MIB  list  contains  thousands  of  network  performance 
parameters  established  in  a  hierarchal  manner  so  user  can  drill  down  to  incredible  detail 
and  select  those  desired.  Most  network  management  bundles  incorporate  the  ability  to 
manage  devices  using  SNMP  including  WUG  and  SLR.  In  addition  to  having  a  vast  array 

42  http://www2.rad.com/networks/1995/snmp/snmp.htm,  Feb  04 

43  Internetworking  Technologies  Handbook,  Cisco 

44  Understanding  SNMP  MIBs,  David  Perkins  and  Evan  McGinnis,  1997,  Prentice  Hall 
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of  information  available  with  SNMP  MIB,  the  protoeol  allows  remote  management  by 
users  of  network  devices.  This  SNMP  function  allows  for  distributed  management  and 
introduces  redundancy  to  management  functions  if  operating  on  multiple  devices. 

c.  Collaboration  Tool  Suite 

Adding  collaborative  technology  is  the  major  conceptual  change  for  the 
fleet  network  operations  environment.  Combining  a  common  network  management 
package  with  instant  group  communications  can  greatly  improve  network  performance. 
The  potential  of  collaborative  technology,  also  known  as  Groupware,  is  remarkable 
because  it  “positively  impacts  the  way  people  communicate  with  each  other,  resulting  in 
improvements  in  the  way  people  work  and  the  decisions  people  make. ”45  Collaborative 
technologies  are  designed  to  provide  members  a  virtual  environment  allowing  the 
exchange  of  information  and  ideas46.  There  are  several  methods  to  electronic 
collaboration  including  email,  instant  messaging,  and  file  sharing  to  name  a  few. 
Collaborative  tool  suites  allow  people  to  stay  connected  without  regard  to  a  physical 
location  and  it  also  “facilitates  group  problem  solving”47.  The  task  here  is  to  identify  the 
collaborative  functions  applicable  to  network  operations  environment  since  it  is  known 
that  collaboration  greatly  adds  to  an  organization’s  effectiveness  and  ability  to 
communicate.  There  are  many  collaborative  products  available  including  Groove, 
Microsoft’s  Live  Meeting,  Blackboard,  WorkNet  by  Avail  technologies,  and  Lotus  Notes 
(to  name  a  few).  The  market  for  collaborative  tools  is  seeing  tremendous  growth  as 
companies  seek  a  competitive  edge  in  the  marketplace48  and  research  has  only  begun  to 
identify  all  the  benefits  this  technology  will  bring49.  To  conduct  the  evaluation 
collaborative  tools.  Groove  software  was  chosen  because  of  its  functionality  and  the 
already  existing  relationship  between  the  US  Navy  and  the  Groove  Networks  Inc. 


45  Decision  Support  Systems  in  the  2D‘  Century,  George  M.  Marakas,  Prentiee  Hall,  1999 

46  http://www.nwfusion.eom/reviews/2003/0728bg.html,  Jan  2004 

47  http://www.usabihtyirst.eom/groupware/intro.txl,  Jan  04 

48  Collaborative  Technology  Takes  on  More  Critical  Role,  Dennis  Callaghan  and  John  S.  Meeright, 
EWeek,  Feb  24,  2003 

49  An  Empirieal  Investigation  of  the  Impaet  of  Eleetronie  Collaboration  Tools  on  the  Performanee  of  a 
Supply  Chain,  Elisabeth  LeFebvre  et  al,  2002,  IEEE  Computer  Soeiety 
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Since  collaboration  primarily  impacts  the  eommunication  methods  within 
groups,  this  will  be  the  first  area  addressed.  One  of  the  most  basic  forms  of  collaboration 
is  electronic  chat  which  is  a  “synchronous  form  of  communication,  closely  resembling 
actual,  real-time  conversations”. 50  This  provides  network  operators  the  ability  to  rapidly 
communicate  since  all  members  of  a  chat  discussion  instantly  see  all  responses 
conveniently  loeated  in  one  plaee.  Often  ehat  software  allows  the  discussion  thread  to  be 
saved  so  the  group  can  have  a  reeord  of  conversations.  Chat  is  an  important  feature  for 
network  operations  because  it  primarily  faeilitates  synehronous  eommunieation. 
However,  it  does  give  group  members  the  ability  to  communicate  asynchronously  if  there 
is  a  record  of  the  conversation  kept.  Maintaining  a  chat  history  in  the  collaborative 
environment  permits  members  to  see  previous  discussions  and  gain  knowledge  already 
shared.  This  lets  members  who  recently  joined  a  eonversation  cateh-up  while  the  other 
users  are  allowed  to  maintain  progress  in  the  conversation.  In  a  network  operations 
environment  administrators  can  use  chat  to  establish  rapid  eommunications  about 
network  performanee,  troubleshooting  faults,  or  general  notifieations  with  ease.  Eaeh 
person  is  instantly  aware  of  the  pertinent  information  and  adding  this  to  the  eommon 
network.  Groove  incorporates  a  chat  function  in  every  available  tool  (file  view,  web 
surfing,  ete.)  so  users  eonstantly  have  the  ability  to  monitor  eommunieations  with  other 
members  of  the  spaee  without  regard  to  the  speeifie  task  being  performed.  Groove  also 
maintains  the  char  history  (when  offline  and  online)  until  it  is  manually  deleted  by  a  user. 

Another  tool  to  be  included  within  the  collaborative  suite  for  the  network 
operations  environment  is  the  ability  to  send  messages  to  individuals  within  the  group. 
While  ehat  is  a  very  useful  medium,  there  are  also  drawbaeks  that  individual  messaging 
ean  overeome.  First,  chat  rooms  often  involve  many  individuals  potentially  causing 
confusion  if  different  discussion  threads  oecur  simultaneous. 5 1  A  messaging  capability 
allows  individual  group  members  to  eommunieate  privately  so  the  entire  group  is  not 
involved.  This  single  capability  enhances  the  potential  for  effeetive  eommunieation  and 
reduces  the  possible  confusion  that  may  occur  within  the  group. 


50  http://www.edtech.vt.edu/edtech/id/ocs/chat.html 

51  http://www.edtech.vt.edu/edtech/id/ocs/chatp2.html,  Jan  04 
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Voice  communications  is  another  capability  that  should  be  included  in  a 
collaborative  network  operations  capability.  Voice  communication  is  widely  used  in  the 
military  but  as  previously  mentioned,  resources  are  limited.  Fortunately,  voice 
communications  can  be  made  possible  within  a  collaborative  environment  using  Voice 
Over  IP  (VoIP).  VoIP  is  often  implemented  in  audio  conferencing  functions  and  allows 
one-to-many  (one  person  talks,  others  listen)  or  many-to-many  (all  can  talk  or  listen 
simultaneously)  conversations.  VoIP  implementations  suffer  from  a  couple  of 
disadvantages  though.  The  main  disadvantage  is  that  bandwidth  is  not  guaranteed  and  to 
be  effective,  VoIP  requires  higher  quality  of  service  than  regular  packet  switched 
standards52.  This  can  cause  conversations  to  be  choppy  because  of  latency  and  jitter 
associated  with  packet  transfer.  Various  organizations  are  trying  to  develop  solutions  for 
this  but  currently  it  remains  a  difficult  problem.  Another  disadvantage  to  audio 
conferencing  is  that  there  typically  is  no  ability  to  record  the  group’s  conversations.  This 
means  that  unlike  chat,  users  cannot  review  the  discussion  thread  later  in  time  so  the 
benefit  is  not  maximized  for  group  members. 

At  a  technical  level  chat,  messaging,  and  audio  exchange  provide  great 
capabilities  for  a  group  and  must  be  included.  From  a  procedural  standpoint  these  tools 
must  be  properly  managed.  Since  these  tools  would  be  used  on  a  DOD  network,  members 
must  adhere  to  the  appropriate  use  policies  set  forth  by  the  chain  of  command.  This 
pertains  to  the  subject  matter  that  is  discussed  or  the  language  being  used  by  participants. 
Once  implemented  users  become  responsible  for  their  behavior  and  appropriate 
enforcement  methods  must  be  used  as  established  by  existing  policy. 

File  sharing  is  the  next  capability  that  can  be  applied  to  the  network 
operations  model.  File  sharing  can  accommodate  a  variety  of  tasks  in  a  network 
operations  environment.  The  biggest  benefit  provided  by  a  file  sharing  function  is  the 
ability  of  all  members  to  have  access  to  the  same  files  and  receive  updates  or  automatic 
downloads  of  the  latest  document  version.  For  example,  this  common  access  to 
documents  permits  fleet  assets  to  readily  view  any  number  of  policies,  procedures,  or 
instructions  all  related  to  the  network  operations  environment.  This  could  be  a  drastic 

52  http://www.tldp.Org/HOWTO/VoIP-HOWTO-3.html#ss3.4,  Jan  04 
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change  in  the  way  the  Navy  disseminates  new  information.  Often  times,  commands  must 
mail  CD-ROMs  to  the  appropriate  commands  when  new  or  updated  instructions  are 
promulgated.  Since  the  mail  service  is  considerably  delayed  eompared  to  electronic 
sharing,  this  imparts  unnecessary  delay  for  the  intended  recipients.  In  addition  to  the 
delay,  parent  commands  incur  the  expense  of  distributing  the  CD-ROMs  to  the  units  that 
require  the  information.  This  beeomes  a  cumbersome  proeess  when  considering  that  in 
exeess  of  300  commands  in  the  fleet  would  need  information  regarding  network 
operations.  Posting  doeuments  to  an  internet  website  is  another  way  to  disseminate 
information  but  this  too  has  its  limitations.  Network  operations  personnel  would  need  to 
actively  seek  the  eurrent  information  posted  to  a  web  site.  In  document  sharing,  group 
members  within  a  virtual  space  are  provided  instant  aecess  (and  possibly  automatic 
updates)  for  the  information  as  long  as  the  collaborative  environment  is  running.  Another 
problem  with  web  pages  is  that  they  require  maintenance  and  significant  effort  for  the 
command  responsible  for  them.  The  time  required  to  update  a  website  is  greater  than  the 
time  required  to  update  a  doeument  in  a  collaborative  file  sharing  environment.  Lastly, 
web  sites  require  additional  actions  to  prevent  unauthorized  personnel  do  not  gain  access. 
This  may  be  a  log-in,  VPN,  or  other  method.  In  a  virtual  eollaborative  spaee,  the  only 
people  that  ean  aceess  the  information  are  those  given  aceess  by  the  spaee  manager  with 
no  additional  overhead  required. 

Applieation  sharing  is  another  area  that  should  be  incorporated  in  a 
network  operations  environment.  In  its  strictest  definition,  application  sharing  is  a 
function  that  allows  “group  participants  to  simultaneously  run  the  same  applieation” 
while  “the  applieation  itself  resides  on  only  one  machine. ”53  Also  known  as  desktop 
sharing,  this  allows  participants  the  permissions  to  use  resourees  on  other  machines.  This 
function  provides  a  tremendous  capability  for  the  network  operations  environment 
because  it  used  to  allow  multiple  elients  the  capability  for  real-time  editing  of  doeuments, 
product/applieation  demonstrations54,  remote  presentations,  or  interactive  training 
sessions55.  As  an  example,  the  fleet  eould  benefit  tremendously  with  the  ability  to 

53  http://www.webopedia.coin/TERM/ A/Application  sharing.html,  Jan  04 

54http://www.lotus.com/products/lotussametime.nst70/f43b214ddec28b8c8525687e00583b48?OpenDo 
cument,  Jan  04 

55  http://www.wiredred.com/epop_application_sharing.html,  Jan  04 
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conduct  remote  training.  Every  command  could  receive  standardized  network  training 
leading  to  improved  network  performanee.  Regional  eommands  responsible  for  network 
performanee  benefit  beeause  they  know  that  fleet  users  are  reeeiving  common 
information  and  fleet  assets  benefit  from  reeeiving  similar  training  aeross  multiple 
platforms.  Looking  further,  application  sharing  would  facilitate  easier  transitions  to  new 
software  through  remote  training,  demonstrations,  and  presentations.  This  would  reduee 
the  overhead  involved  with  new  software  installations,  a  relatively  frequent  oeeurrenee 
for  network  operations.  An  additional  benefit  to  applieation  sharing  is  that  it  eould 
provide  another  avenue  for  remote  device  management.  It  was  mentioned  earlier  that 
SNMP  ineorporates  remote  management  funetionality  as  part  of  the  standard  but 
unfortunately  SNMP  also  has  seeurity  pitfalls  that  could  allow  unauthorized  users 
tremendous  eontrol  of  network  deviees.  Is  it  eompletely  unaeeeptable  for  unauthorized 
persons  to  gain  access,  let  alone  control  of  fleet  networks  beeause  of  the  variety  of 
missions  that  the  networks  support.  Limiting  SNMP  controls  enhances  security  but  also 
limits  capabilities  that  the  network  managers  could  use  to  improve  network  performance. 
Adding  applieation  sharing  in  a  collaborative  space  lets  users  authorize  other  group 
members  to  aecess  a  resouree,  like  a  network  management  suite  for  example.  This  would 
supply  network  managers’  tremendous  eapabilities  while  alleviating  some  seeurity 
eoneerns  assoeiated  with  remote  deviee  management. 

The  whiteboard  function  is  another  collaborative  feature  that  can  improve 
the  network  operations  environment.  Collaborative  whiteboards  were  designed  to  change 
regular  chalk  or  dry  erase  boards  into  interaetive  environments  where  partieipants  eould 
see  and  make  ehanges  in  a  eommon  setting.  Anything  written  or  drawn  onto  the  board  is 
eaptured  on  a  computer  (or  network)  and  eaeh  member  of  the  group  can  mark  up 
whatever  is  being  presented.  These  are  often  used  for  team  meetings,  distance  learning, 
and  networked  brainstorming  sessions56.  The  typieal  eleetronie  whiteboard  funetions  can 
easily  be  integrated  into  network  operations.  The  typieal  functions  of  a  whiteboard  are 
only  one  aspeet  to  its  use  in  the  network  operations  environment.  A  hypothetieal  example 
points  to  the  potential  of  whiteboard  funetions  within  network  operations.  Let’s  say  that 
various  network  managers  are  viewing  the  same  network  performance  information  in  a 
56  http://www.multimedia.co.th/e-whiteboard.htm,  Jan  04 
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collaborative  environment  with  whiteboard  functionality.  If  a  problem  or  signifieant 
event  happens,  an  individual  could  mark  up  the  sereen  for  others  to  see,  thereby  redueing 
further  the  effort  for  all  members  of  the  group  to  identify  the  problem.  This  ability 
reinforees  the  other  methods  of  communieation  within  the  eollaborative  environment. 

An  awareness  feature  should  also  be  ineluded  in  a  network  operations 
model  collaborative  suite.  This  is  the  ability  of  members  to  know  the  status  of  other 
members  in  a  virtual  spaee.  This  is  important  beeause  members  ean  instantly  see  who  is 
working  in  that  spaee.  If  a  member  sees  another  member  present  in  a  virtual  spaee,  that 
person  ean  quickly  know  who  is  available  to  communicate  with  about  a  partieular  issue. 
It  also  adds  a  level  of  seeurity  beeause  group  members  ean  verify  that  only  authorized 
people  are  in  the  virtual  space  sharing  information. 

d.  System  Architecture 

This  transformed  model  foeuses  primarily  on  the  software  solution  for  the 
network  operations  environment  based  on  COTS  technology.  Before  any  software  is 
purchased  or  installed  it  is  important  to  consider  how  software  at  node  A  will  internet 
with  node  B.  If  this  is  incorreetly  established,  the  system  will  be  much  less  useful  and  in 
its  worst  ease,  no  oommunieation  ean  oeeur  beeause  of  a  laek  of  interoperability.  For  this 
paper,  the  foeus  is  on  high-level  network  layers  (OSI  layer  4  and  above)  and  more 
speeifieally  whether  network  operations  should  be  based  on  elient-server  or  peer-to-peer 
architeetures. 

Client-server  arehiteetures  involve  two  types  of  applieations.  The  first 
waits  passively  (servers)  for  others  to  start  oommunieation.  The  applioation  that  starts  the 
oommunieation  is  oalled  the  olient57.  This  ean  be  explained  using  typioal  Internet 
browsing  as  an  example.  Assuming  oonneotivity  already  exists  (OSI  layers  1-3),  a  user 
types  the  uniform  resouroe  looator  (URL)  into  a  web  browser  and  the  appropriate  web 
page  appears  once  transferred.  When  the  user  enters  the  URL  or  selects  a  hyperlink,  the 
browser  aots  as  the  olient  and  sends  a  request  to  the  server  holding  the  appropriate  file. 
The  server  responds  to  the  request,  establishes  a  session  with  the  olient,  transfers  the  web 
page,  and  it  is  finally  displayed  in  the  olient  maohine.  In  this  case,  the  server  does  nothing 

unless  it  reoeives  a  request  from  a  olient.  Servers  typioally  reside  in  one  plaoe  and  their 
57  Computer  Networks  and  Internets ,  Douglas  E.  Comer,  2001,  Prentice  Hall 
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address  doesn’t  ehange.  If  server  address  ehanges,  it  ean  be  diffieult  for  elients  to  find  the 
desired  information  afterwards.  The  elient-server  arehiteeture  is  not  appropriate  for  the 
transformed  network  operations  model  beeause  it  is  diffieult  to  seale  in  a  dynamie, 
widely  distributed  network.  It  is  designed  to  operate  in  a  eentralized  network 
environment  with  servers  remaining  available  for  elients  to  use.  This  does  not  suit  the 
needs  of  the  fleet  beeause  of  the  dynamie  nature  of  operations. 

In  peer-to-peer  arehiteetures,  the  foeus  is  to  pool  and  eoordinate  network 
resourees  in  a  deeentralized  environment  ineluding  “unstable  eonneetivity  and 
unpredietable  IP  addresses. ”58  Peer-to-peer  also  “enhanees  the  utilization  of  information, 
bandwidth,  and  eomputing  resouroes”59.  The  nature  of  peer-to-peer  suggests  that  it  is 
perfeetly  aligned  for  use  in  the  fleet.  Despite  the  natural  fit  peer-to-peer  has  in  the  fleet, 
there  are  disadvantages.  In  large  network  environments,  resourees  for  individual  nodes 
ean  be  limited  beeause  it  is  diffieult  to  find  the  appropriate  resouree  loeation.  The  time 
required  to  download  information  is  an  issue  that  needs  improvement  as  well^o.  Finally, 
the  peer-to-peer  model  is  somewhat  irrational  beeause  it  assumes  that  users  will  adhere  to 
protoeols  without  making  adjustments  for  personal  gain  (even  though  they  possess  the 
eapability)6i. 


B,  DECISION  SUPPORT  SYSTEM 

The  addition  of  a  Deeision  Support  System  (DSS)  is  not  a  new  eoneept  for 
network  operations.  Most  network  management  suites  ineorporate  limited  DSS 
funetionality  but  this  doesn’t  neeessarily  translate  to  easier  network  management.  DSS 
teehnology  eurrently  has  limitations  and  takes  signifieant  effort  on  the  part  of  the  user  to 
provide  deeision  making  easier.  Current  researeh  involving  intelligent  agents  and  the 
Control  of  Agent  Based  Systems  (CoABS)62  suggest  that  deeision  support  systems  are 
about  to  undergo  a  dramatie  shift  in  eapability.  The  new  eapabilities  will  greatly  reduee 

58  http://people.cs.uchicago.edu/~anda/papers/foster_grid_vs_p2p.pdf,  Feb  04 

59  http://dmi.ensica.fr/article.php3?id_article=229,  Feb  04 

50  http://dmi.ensica.fr/article.php3?id_article=229,  Feb  04 

51  http://www.eecs.harvard.edu/~syrah/paptoers/iptps-03/iptps-03.pdf,  Feb  04 

52  http://coabs.globalinfotek.com,  Feb  04 
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the  effort  require  by  users  to  manipulate  information  systems  through  autonomous 
software  agents.  With  this  in  mind,  this  researeh  seeks  to  highlight  the  fundamental  DSS 
eomponents  that  should  be  applied  to  network  operations. 

1.  Database 

Databases  are  “integrated  eolleetions  of  data,  organized,  and  stored  in  a  manner 
that  faeilitates  easy  retrieval”  and  when  ineorporated  into  a  deeision  support  system 
(DSS)  “provide  relevant  data  for  the  partieular  deeision  oontext”63.  The  information 
presented  to  the  user  is  taken  from  the  database  making  it  the  deeision  support  system 
foundation. 

The  database  is  extremely  important  beeause  it  may  be  used  by  multiple  people 
and  applieations.  In  order  to  effeetively  deliver  data  to  the  serviees  and  people  properly,  it 
must  be  established  in  a  logieal  and  hierarehal  manner.  Databases  are  eomplex  and 
require  a  earefully  designed  schema,  or  method  to  store  and  retrieve  data,  to  be  effective. 

Fortunately  for  network  operations,  databases  are  already  incorporated  into 
network  management  software.  Software  packages  including  SLR  and  WUG  contain 
mechanisms  to  easily  track  and  retrieve  information  pertaining  to  network  performance  in 
a  variety  of  ways  including  graphs  and  charts.  This  alleviates  considerable  effort  for  the 
network  administrators  and  permits  them  to  focus  more  on  the  network  itself.  As  such, 
further  discussion  pertaining  to  the  database  is  not  warranted. 

2.  Model  Base 

The  model  base  is  a  collection  of  tools  that  allow  data  to  be  analyzed 
quantitatively  using  a  variety  of  methods.  There  are  optimization,  financial,  and  statistical 
models  to  name  a  few.  The  model  base  is  a  very  distinguishing  DSS  characteristic  for 
information  systems64  because  these  powerful  tools  simplify  reality  by  looking  at  sample 
data  to  generate  predictions  in  a  given  decision  context. 

Network  management  software  incorporates  some  model  base  functionality  and 
allows  statistical  analysis  of  network  performance.  Typical  implementations  include 


63  Decision  Support  Systems  in  the  2D‘  Century,  George  M.  Marakas,  Prentiee  Hall,  1999 

64  Decision  Support  Systems  in  the  2D‘  Century,  George  M.  Marakas,  Prentiee  Hall,  1999 
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information  about  node  response  time,  paeket  loss,  eommunity  string,  throughput, 
utilization  pereentages,  peak  bit  rates,  paekets  per  seeond,  paeket  size,  error,  and  paeket 
diseards. 

Additional  efforts  should  be  applied  to  several  model  types  that  are  pertinent  to 
network  operations.  It  may  inelude  optimal  path  models  to  find  the  appropriate 
information  path  flow.  The  model  may  seek  to  find  the  maximum  flow  for  a  network,  and 
models  seek  to  find  the  shortest  path  for  information  to  travel.  Transport  models  ean  be 
developed  to  optimize  the  distribution  aeross  multiple  eonneetion  paths  eontributing  to 
better  network  deviee  load  sharing.  Additional  models  may  be  ineluded  to  replieate 
expeeted  performanee  based  on  the  network  arehiteeture. 

Network  modeling  tools  (ex.,  OPNET  IT  Guru)  that  ean  simulate  a  real  network 
should  also  be  ineluded  as  part  of  the  model  base  funetionality  ineluded  within  standard 
network  management  software.  These  tools  allow  operators  to  generate  anticipated 
network  performance  characteristics  based  on  the  components,  connections,  and  services 
in  use.  Using  these  tools,  network  administrators  can  establish  virtual  networks  to  test 
network  architectures  and  performance  before  the  actual  installation  occurs.  Modeling 
tools  can  also  be  used  for  troubleshooting,  system  optimization,  and  configuration 
management  functions  as  well.  An  administrator  may  recreate  a  given  network 
architecture,  services,  or  equipment  settings  to  determine  where  problems  exist  or  avoid 
them  if  accomplished  prior  to  deployment.  The  bottom  line  is  that  network  modeling 
improves  performance  and  reduces  the  time  required  by  operators  to  maintain  networks. 

3.  Knowledge  Base 

The  knowledge  base  can  be  considered  a  repository  containing  data  about 
previous  experiences.  Technically  speaking,  it  is  “the  rules,  heuristics,  boundaries, 
constraints,  previous  outcomes,  and  other  knowledge  programmed  into  the  DSS  or 
acquired  through  repeated  use. ”65  Unlike  the  database,  the  knowledge  base  contains 
information  for  a  single  problem  domain.  It  does  not  usually  have  items  that  are  directly 
related  to  the  decision  context,  in  this  case  network  operations.  Driven  by  the  database, 
the  knowledge  base  is  used  to  exchange  information's  and  automate  routine  processes67. 

65  Decision  Support  Systems  in  the  2D‘  Century,  George  M.  Marakas,  Prentice  Hall,  1999 

66  http://www.theworkinggroup.ca/collaboration-benefits.html,  Jan  2004 
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The  items  in  the  knowledge  base  are  used  for  reasoning  and  are  either  facts  or  hypothesis. 
The  facts  the  things  believed  to  be  true  at  a  given  time  where  the  hypothesis  expresses  the 
relationships  existing  between  facts. 68  The  knowledge  base  for  network  operations  is 
gained  by  obtaining  individual  performance  parameters.  As  user  established  thresholds 
are  met,  the  system  recognizes  a  particular  event.  The  system  then  updates  the 
information  presented  to  the  user.  As  applied  to  the  network  operations  model  the 
knowledge  base  can  be  explained  using  an  SNMP  illustration.  The  agents  trap  the  facts, 
the  specific  criteria  requested  by  the  SNMP  Manager  that  exist  for  a  given  device.  The 
hypothesis  is  established  once  the  Manager  receives  the  response  from  the  Agent.  The 
Manager  evaluates  the  condition  of  network  operations  based  on  the  facts  presented  to  it. 
If  appropriate,  the  Manager  may  recognize  a  significant  network  event  and  change  the 
status  information  for  the  user.  In  other  cases  the  system  will  observe  unchanged 
conditions  that  require  no  additional  actions. 

4.  User  Interface 

The  user  interface  is  the  front  end  of  the  system  that  the  user  sees  when  accessing 
components.  It  is  the  tool  that  allows  a  human  being  to  interact  with  a  machine. 69  In 
presenting  itself  to  the  user,  the  interface  hides  the  underlying  structure  and  is  the  conduit 
between  the  user  and  the  system.  “The  easier  it  is  for  a  user  to  access  the  system  the 
better  the  interface. ”70  A  common  interface,  an  interface  relatively  familiar  to  many 
users,  is  successful  when  its  operations  are  recognizable  and  fairly  intuitive  for  the  users. 
The  importance  of  the  interface  cannot  be  overlooked  because  if  poorly  designed,  the 
information  presented  to  the  user  is  much  less  useful.  There  is  an  entire  research  area 
dedicated  to  the  study  of  human-system  integration.  This  field  includes  computer 
scientists  and  psychologists  looking  towards  “perceptual,  cognitive,  and  motor  theories 
and  models  of  human  performance’’^!  to  best  design  user  interfaces.  As  a  result,  this 
paper  barely  scratches  the  surface. 


67  Groupware,  David  Coleman,  1997,  Prentice  Hall 

68  Decision  Support  Systems  in  the  2D‘  Century,  George  M.  Marakas,  Prentice  Hall,  1999 
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70  Decision  Support  Systems  in  the  2D‘  Century,  George  M.  Marakas,  Prentice  Hall,  1999 
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The  basic  problem  is  that  one  interface  must  be  used  by  multiple  people  and  no 
one  person  is  the  same.  What  is  easy  for  one  person  might  be  very  difficult  for  another. 
The  interface  does  not  do  its  job  if  it  is  not  easy  to  use  for  all  involved.  The  two  primary 
components  to  the  interface  are  the  communication  language  and  presentation 
language. 72  The  communication  language  is  the  physical  means  the  system  is  accessed  by 
the  user.  It  may  include  the  keyboard,  mouse,  scanner,  joystick  to  name  some  examples. 
The  presentation  language  is  what  the  user  experiences.  Windows,  sounds,  icons,  tables, 
and  graphs  are  examples  of  the  presentation  language.  The  goal  is  for  the  DSS  interface 
to  be  “user-friendly”  and  can’t  be  achieved  unless  both  the  communication  and 
presentation  languages  are  well  suited  to  needs  of  the  user.73  Since  this  paper  is  using 
existing  products  to  establish  the  model  for  future  operations,  the  input  for 

5.  Users 

The  goal  of  the  transformed  network  operations  model  is  to  identify  the 
capabilities  and  functions  that  will  improve  the  management  of  fleet  information 
networks.  This  vision  for  a  network  operations  model  will  not  achieve  the  goal  if  the 
users  are  not  considered  because  in  the  end,  the  major  decisions  are  accomplished  by  the 
system  users.  There  are  a  variety  of  important  issues  associated  with  the  user  including 
user  skill  set,  individual  motivations,  knowledge,  use  patterns,  and  organizational  roles. 

The  network  operation  system  users  will  be  highly  motivated  professional  sailors 
that  have  volunteered  to  join  the  Navy  in  an  information  technology  (IT)  capacity.  They 
will  be  familiar  with  information  networks  and  receive  considerable  formal  training  in 
relevant  areas.  Once  sailors  complete  formal  school  house  training,  they  report  to 
operational  commands  and  begin  personal  qualifications  and  on-the-job  training  (OJT). 
Until  they  are  fully  qualified,  new  users  work  under  the  supervision  of  more  experienced 
personnel.  The  way  the  Navy  trains  sailors  is  undergoing  a  dramatic  change  and  is  likely 
to  improve  the  process.  The  new  method  for  training  will  include  revised  school  house 
instruction  that  is  more  streamlined  and  focused  on  relevant  topics.  Sailors  will  be 
encouraged  to  pursue  civilian  certifications  in  additional  to  the  qualification  programs 
resident  at  each  command. 

72  Decision  Support  Systems  in  the  2D‘  Century,  George  M.  Marakas,  Prentiee  Hall,  1999 
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The  organizational  roles  the  will  fill  will  vary  depending  on  the  operational 
eontext  of  the  command.  Currently,  only  tactical  information  networks  are  managed  by 
sailors.  Both  classified  and  unclassified  W/LANs  are  run  by  shore  installations.  Under  the 
transformed  network  operations  model,  users  may  serve  as  an  administrator  for  individual 
ships  or  groups  of  ships.  The  user’s  role  will  be  determined  by  the  role  his/her  command 
is  assigned  for  a  strike  group  similar  to  the  methods  used  to  assign  responsibility  for 
tactical  networks.  The  user  will  only  manage  a  group  of  ships  if  the  command  is  assigned 
the  responsibility. 

C.  AUGMENTED  REALITY  TECHNOLOGY 

Augmented  reality  (AR)  has  the  potential  to  radically  transform  network 
operations  because  of  its  visualization  capabilities.  The  purpose  of  AR  is  to  superimpose 
computer  generated  information  (text,  images,  or  graphics)  onto  the  real-world  sensory 
inputs  naturally  gathered  by  users.  The  biggest  potential  benefit  provided  by  AR 
technology  to  the  network  operations  environment  is  the  potential  for  “unhindered 
cooperation  of  different  user  viewing  the  same  visualization.”74  Once  developed,  this 
capability  will  drastically  multiply  the  advantages  of  collaboration  since  users  will  be 
able  to  manipulate  the  information  being  presented  and  share  that  with  others.  Applying 
AR  technology  where  all  participants  have  the  ability  to  visualize  and  alter  the 
information  presented  for  others  takes  collaboration  and  network  operations  to  a  higher 
level  of  performance  not  currently  possible  with  other  technologies.  The  potential  for 
mobile  network  management  also  adds  to  flexibility  for  users.  Users  may  be  able  to  move 
around  and  accomplish  other  tasks  while  receiving  network  management  information. 
This  may  alleviate  the  need  to  dedicate  people  to  fixed  NOC  sites  in  the  future. 

1,  Technology  Definition 

a.  General  Discussion 

Augmented  reality  is  an  emerging  technology  where  computer  generated 
graphics  or  information  is  integrated  into  our  natural  environments^s.  There  is  a  large 
amount  of  research  being  done  but  very  little  practical  application  of  the  technology.  AR 

74  http://www.cg.tuwien.ac.at/research/vr/studierstube/CGA98.pdf,  Feb  04 

75  http://www.howstuffworks.com/augmented-reality.htm,  Feb  04 
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allows  people  to  use  their  natural  senses  to  gather  real-world  inputs  and  have  augmented 
reality  provide  additional  real-time  information  about  the  surroundings.  This  is  drastically 
different  from  virtual  reality  where  the  majority  of  sensory  inputs  are  generated  by  the 
computer  and  users  are  immersed  in  the  three  dimensional  computer  environments76.  The 
three  basic  components  of  augmented  reality  equipment  are  a  head-mounted  display 
(HMD),  a  tracking  system,  and  a  mobile  computer77. 

There  are  several  types  head  mounted  displays  on  the  market  but  many  are 
still  bulky  and  cumbersome  to  wear.  There  are  also  HMD  units  that  are  simple 
lightweight  glasses  with  a  light  source  projector.  Aside  from  the  physical  characteristics 
of  the  equipment,  the  two  methods  used  to  provide  the  user  with  inputs  are  video  see- 
through  and  optical  see-through78.  The  video  see-through  approach  uses  cameras  to 
gather  images  and  the  images  are  projected  in  real-time  with  the  augmented  computer 
information  or  graphics  to  the  wearer.  Optical  see-through  displays  present  graphics  or 
information  on  top  of  the  natural  visual  images  captured  by  users  instead  of  using 
cameras. 

The  tracking  systems  incorporated  into  augmented  reality  systems  are 
used  to  provide  orientation  information  about  the  user  to  the  computer.  This  is  the  most 
difficult  part  to  augmented  reality  since  the  computer  needs  to  monitor  the  geographic 
location  of  the  user,  the  position  of  the  head,  and  position  of  the  eyes79.  It  is  important  to 
note  that  coordinates  are  not  enough  to  establish  a  user’s  location.  The  important  piece  of 
information  is  the  location  relative  to  the  user’s  surroundings.  Examples  of  the  type  of 
required  information  include  whether  the  user  in  the  middle  of  the  street,  in  front  of  a 
door,  looking  away,  or  moving.  These  issues  are  part  of  a  concept  called  “view 
management”80  which  is  concerned  with  how  information  is  presented  to  the  user  in  the 
augmented  reality  environment. 


76  http://www.cs.iupui.edu/~tuceryaii/AR/AR.html,  Feb  04 

77  http://computer.howstuffworks.com/augmented-realityl.htm,  Feb  04 

78  http://computer.howstuffworks.com/augmented-reality2.htm,  Feb  04 

79  http://computer.howstuffworks.com/augmented-reality3.htm,  Feb  04 
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The  wearable  computer  is  the  last  component  to  augmented  reality 
systems.  Wearable  computers  are  the  weak  point  right  now  for  the  technology  because 
the  processing  power  and  graphics  capabilities  are  limited.  Computing  power  is 
improving  but  in  the  foreseeable  future  wearable  and  mobile  computing  will  lack 
capabilities  that  personal  computers  have.  Lastly,  the  graphic  accelerators  used  with  more 
advanced  AR  displays  only  used  for  researchsi  and  have  not  transitioned  to  the 
wearable/mobile  computing  marketplace. 

b.  Interface  Between  Hardware  and  Software 
There  are  a  few  ways  that  users  can  interface  with  the  augmented  reality 
equipment  inputs  to  affect  software  actions.  The  simple  implementations  are  based  on 
standard  computing  interfaces  and  include  small  wearable  keyboards  and  wearable 
pointing  devices.  The  next  level  of  interface  technology  includes  personal  digital 
assistants,  graphics  tablets,  video  cameras,  and  video  projectors  to  present  augmented 
reality  information82.  Other  devices  include  instrumented  gloves  that  permit  users  to 
manipulate  virtual  objects83.  The  most  revolutionary  interface  technology  involved  with 
AR  is  voice  recognition. 

The  physical  differences  are  one  aspect  to  augmented  reality  but  the 
largest  benefit  is  combining  the  software  and  hardware.  The  way  information  is  perceived 
is  enhanced  when  users  are  able  to  manipulate  the  presentation84.  This  may  include 
manipulation  of  a  virtual  object  or  drilling  down  for  additional  information.  Since  the 
augmented  reality  system  is  oriented  to  the  user’s  point  of  view,  it  is  inherently 
interactive  and  personalized  to  a  level  not  possible  with  other  techno logies85. 


81  http://wwwl.cs.columbia.edu/graphics/projects/mars/mars.html,  Feb  04 

82http  ://dehvery  .acm.  org/1 0 . 1 1 45/3  50000/3 477 1 4/p  1 85  - 
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There  are  three  ways  to  incorporate  AR  technology  as  suggested  by 
Mackay86.  The  technology  can  be  used  to  augment  the  user,  the  object,  or  the 
environment.  Augmenting  the  user  is  when  the  technology  is  attached  to  a  person  using  a 
HMD,  gloves,  or  goggles  for  example.  It  is  also  possible  to  augment  the  user  with  PDAs 
and  graphic  tablets87.  Augmenting  the  object  means  that  the  AR  device  is  connected  to  an 
object  that  can  be  manipulated.  Augmenting  the  environment  occurs  when  the  area 
surrounding  the  user  or  object  is  embedded  with  projected  information  and  imagery. 

c.  Uses  of  A  ugmented  Reality 

As  suggested  by  Wendy  Mackay,  it  is  important  to  consider  the  existing 
real-world  process  to  properly  determine  how  augmented  reality  can  be  used^s.  One 
measure  to  assist  with  the  decision  of  implementing  AR  is  whether  the  existing  process 
contains  notable  distinctiveness  that  is  not  easily  repeated  with  standard  computing 
interfaces  (i.e.  keyboard  &  mouse).  If  this  is  the  case,  then  augmented  reality  may  be  a 
viable  solution.  The  next  consideration  is  how  well  the  virtual  and  real  information  can 
be  integrated.  The  two  must  appear  seamless  once  implemented  and  if  this  cannot  be 
achieved,  the  AR  technology  may  not  be  the  answer.  Another  issue  specifically  related  to 
the  interface  is  how  create  the  presentation  so  the  user  can  recognize  the  difference 
between  augmented  and  real  information.  Lastly,  AR  should  be  used  to  improve  the 
existing  world  and  not  replace  it.  To  do  this,  the  effect  of  AR  should  let  users  interact 
naturally  with  objects  and  the  environment  while  providing  information  to  add  to  the 
experience. 

There  is  an  assortment  of  research  concerned  with  how  to  apply 
augmented  reality  technology.  Certain  research  focuses  on  specific  problem  domains 
while  others  suggest  in  general  terms  that  there  is  no  limit  to  what  AR  can  be  applied 
towards. 

86http://delivery.acm.org/10.1145/950000/948498/pl3- 
mackay.pdf?keyl=948498&key2=2277195701&colLGUIDE&dLACM&CFID=16358195&CFTOKEN= 
7927296,  Feb  04 
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Mihran  Tuceryan89  suggests  that  AR  can  be  used  in  mechanical  repair, 
interior  design  modeling,  computer  aided  surgery,  manufacturing  and  road  repair.  There 
are  actually  several  groups  working  to  apply  AR  to  the  medical  field  including  the 
University  of  North  Carolina  (Chapel  Hill)90.  The  Defense  Advanced  Research  Projects 
Agency  (DARPA)  is  funding  a  variety  of  groups  conducting  AR  research  but  most 
notably  is  concerned  with  battlefield  visualization.  Called  the  Battlefield  Augmented 
Reality  System  (BARS)9i  this  research  is  being  conducted  at  several  universities 
including  Columbia,  the  Massachusetts  Institute  of  Technology,  the  Georgia  Institute  of 
Technology,  and  the  Naval  Research  Laboratory.  Other  suggested  uses  include  creating 
“electronic  paper”92  where  the  usefulness  of  physical  documents  in  increased  by 
incorporating  AR  technology.  The  Boeing  Corporation  has  developed  an  AR  system  so 
mechanics  can  be  guided  “step-by-step”  through  a  process  in  the  hopes  that  errors  will  be 
less  frequent  and  productivity  and  knowledge  are  increased93.  What  is  evident  is  that 
most  AR  uses  have  not  reached  a  practical  level  and  most  current  uses  exist  only  in  the 
prototype  stage. 

2.  Applying  AR  to  an  Improved  Network  Operations  Model 
a.  Desired  Capabilities 

As  already  discussed,  there  are  numerous  areas  where  AR  can  be  applied. 
In  this  section,  the  focus  is  identifying  the  desired  capabilities  for  a  transformed  network 
operations  model.  This  is  accomplished  by  looking  at  the  current  uses  of  AR  technology 
and  applying  the  appropriate  capabilities.  In  the  network  operations  environment, 
information  and  visualization  are  the  key  and  AR  technology  can  provide  several  useful 
features. 


89  http://www.cs.iupui.edu/~tuceryaii/AR/applications.html,  Feb  04 

90  http://www.cs.unc.edu/~us,  Feb  04 

91  http://www.ait.nrl.navy.mil/vrlab/projects/BARS/BARS.html,  Feb  04 
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The  AR  technology  must  allow  network  managers  in  the  NOC  an  ability 
to  visualize  network  performance  in  a  multi-dimensional  manner.  As  previously 
discussed,  network  management  software  allows  administrators  to  visualize  network 
performance  but  provides  a  limited  capability  to  drill  down  to  various  levels  on  the 
network.  Solarwinds  provide  a  summary  view  of  network  connections  in  a  tabular  form 
including  status  and  basic  information.  In  What’s  Up  Gold,  the  network  representation  is 
graphical  but  also  only  allows  users  to  pull  up  cursory  information.  In  both  cases,  users 
must  manually  sort  through  various  pull-down  windows,  tabs,  or  modules  to  gather 
additional  information.  AR  equipment  could  allow  users  the  ability  to  focus  on  a 
particular  network  device  and  select  information  with  a  click  of  the  mouse  or  point  of  the 
finger  getting  more  granular  information  with  each  attempt.  For  example,  assume  that  a 
network  management  package  recognizes  that  a  network  device  interface  and  is  not 
working  because  traffic  flow  is  flowing  through  it.  With  that  prompt,  AR  equipment 
could  instantly  present  the  device  and  the  interface  visually  so  the  user  easily  recognizes 
the  problem.  AR  would  not  only  show  the  problem  but  also  instantly  shows  the  impact  of 
that  fault  since  the  affected  nodes  connected  to  that  interface  are  shown  as  well.  It  is 
possible  to  determine  this  information  with  existing  software,  but  it  is  much  more 
difficult  and  requires  more  actions  and  interpretation  by  the  user. 

AR  should  have  the  ability  to  visualize  packet  collisions.  This  occurs  on 
networks  are  collisions  when  packets  of  information  interfere  with  one  another  and  do 
not  reach  the  destination.  Depending  on  the  protocol  in  use,  the  data  either  needs  to  be 
retransmitted  or  gets  lost.  When  high  packet  loss  or  retransmission  occurs,  network 
performance  becomes  seriously  degraded  and  certain  network  services  cannot  be  used  (ex 
VoIP).  Current  network  operations  techniques  do  not  allow  users  to  identify  specifically 
where  collisions  are  occurring  and  is  a  very  difficult  problem  to  overcome.  Using  AR 
technology,  NOC  personnel  could  be  shown  the  place  where  collisions  are  occurring,  and 
then  determine  the  extent  of  the  problem  so  the  appropriate  action  could  be  taken. 

AR  technology  should  also  provide  the  ability  to  visualize  bottlenecks  in 

network  traffic  flow.  Imagine  a  network  manager  located  on  a  ship  is  experiencing 

greater  than  expected  network  latency  and  data  throughput  is  lower  that  it  should  be. 

Having  AR  provide  a  visual  interpretation  of  the  ICMP  TraceRoute  where  the  person 
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could  use  the  presentation  to  easily  determine  where  problems  exist.  Onee  the  route  is 
visualized  and  the  problem  loeation  is  identified,  the  user  ean  then  drill  down  into  that 
device  to  determine  what  the  problem  might  be.  Using  eurrent  methods,  traffie 
bottlenecks  can  be  very  diffieult  and  time  eonsuming  to  find.  Applying  AR  to  the 
problem  would  improve  the  proeess  considerably. 

b.  Augmented  Reality  Benefits 

Augmented  reality  will  provide  signifieant  benefits  to  the  network 
operations  environment.  The  information  presented  is  fused  from  real-world  sensory 
inputs  and  computer  information.  Instead  of  redefining  a  person’s  natural  surroundings,  it 
enhances  them.  AR  technology  provides  information  that  eomputers  eannot  easily 
duplieate94. 

The  most  noteworthy  benefit  of  AR  is  the  capability  to  present  a  problem 
visually  in  addition  to  the  standard  information  network  management  suites  provide. 
Networks  are  eomplieated  systems  and  the  ability  to  see  things  greatly  inereases  user 
understanding  resulting  in  signifieantly  greater  situational  awareness  for  the  operators. 
With  improved  understanding  and  awareness,  the  deeisions  made  by  the  users  will  be 
mueh  and  this  is  eritieal  sinee  the  importanee  of  networks  in  taetieal  environments  is 
eontinually  growing. 

Lastly,  augmented  reality  teehnology  is  being  researehed  in  several  areas 
with  different  methods  of  implementation.  This  evidenee  suggests  there  is  a  tremendous 
amount  of  flexibility  that  AR.  This  flexibility  allows  the  teehnology  to  be  properly 
aligned  with  objeetives  and  is  more  likely  to  be  sueeessful  aeeomplishing  tasks. 

c.  Augmented  Reality  Disadvantages 

While  augmented  reality  holds  great  promise  for  the  transformed  network 
operations  model,  there  are  disadvantages  to  the  teehnology  that  must  be  addressed. 

The  first  of  those  is  the  eost  of  the  augmented  reality  equipment.  Wearable 
eomputers  are  drastieally  more  expensive  than  desktops  and  laptops.  As  an  example,  a 
personal  eomputers  (desktop)  with  a  Pentium  4  proeessor  operating  at  3.4  GHz  and  4  GB 
of  RAM  eosts  approximately  $3900.  A  wearable  eomputer  eompany’s  primary  deviee  is 

94  http://www.se.rit.edu/~jrv/research/ar/introduction.html,  Feb  04 
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powered  by  a  Celeron  500  MHz  processor  with  maximum  256  MB  of  memory  (RAM) 
that  cannot  be  upgraded.  Even  though  it  is  significantly  less  capable,  the  wearable 
computer  costs  approximately  $5,500  (without  accessories)  because  it  is  smaller  and  is 
forced  to  handle  several  problems  that  the  desktop  is  can  easily  overcome  (like  power 
supply  and  heat  dissipation).  This  does  not  include  the  cost  of  displays,  or  the  tracking 
equipment  used  for  orientation.  An  individual  AR  unit  can  cost  in  excess  of  $10,000 
when  fully  outfitted.  Although  network  operations  are  an  essential  part  of  the  Navy’s 
mission,  the  current  costs  of  AR  equipment  are  prohibitive  when  compared  with  other 
fleet  requirements. 

The  next  problem  is  the  level  of  technological  maturity.  AR  is  still  in  the 
very  early  stages  of  development  and  only  prototype  versions  were  discovered  while 
conducting  research  for  this  paper.  While  evidence  of  its  potential  does  exist,  it  is  not 
ready  for  near-term  deployment  into  the  fleet.  Further  research  is  required  to 
quantitatively  determine  if  AR  is  suitable  for  network  operations.  This  technological 
immaturity  also  means  that  a  solution  is  not  currently  available  from  industry.  AR 
software  would  require  development  and  this  would  further  add  to  the  costs  of 
acquisition. 

Lastly,  most  fully  capable  AR  equipment  sets  are  still  cumbersome  and 
uncomfortable.  The  worst  example  indicated  that  a  set  of  AR  equipment  weighed  28 
pounds.  This  presents  difficulties  for  the  user  and  detracts  from  their  ability  to  properly 
conduct  network  management.  In  addition  to  user  discomfort,  cumbersome  wearable 
equipment  is  not  suited  for  shipboard  employment.  Passageways  are  narrow,  ladders  are 
steep,  and  objects  protrude  from  all  directions. 


63 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


64 


V.  TEST  AND  EVALUATION 


Testing  and  evaluation  is  an  integral  part  to  the  researeh  eondueted  for  an 
improved  network  operations  model.  The  methods  identified  for  future  network 
operations  were  derived  from  a  eombination  of  methods  ineluding  a  review  of  existing 
researeh,  testing  and  evaluation  in  a  eontrolled  lab  environment,  and  test  and  evaluation 
during  a  dynamie  field  experiment.  The  goal  of  the  testing  and  evaluation  was  to  validate 
the  network  operations  eore  eapabilities  identified  during  researeh.  Evaluation  was  the 
primary  method  used  to  eonfirm  the  researeh. 

Network  management  is  not  a  new  area  so  this  was  the  most  straightforward 
testing  eondueted.  Existing  network  management  software  paekages  (Solarwinds,  What’s 
Up  Gold)  were  used  to  evaluate  the  eore  network  management  funetions  onee  an 
understanding  of  eurrent  network  operations  was  obtained.  Both  software  paekages 
ineluded  a  plethora  of  features  intended  to  aide  network  managers  but  only  the  features 
applieable  to  the  eore  network  operations  eapabilities  was  tested. 

Testing  for  Deeision  Support  Systems  was  also  eondueted  using  existing  tools  but 
on  a  limited  seale.  The  Groove  software  suite  was  used  to  test  and  evaluate  various  peer- 
to-peer  eollaborative  funetions  while  other  software  paekages  ineluding  Solarwinds, 
Ipswiteh’s  What’s  Up  Gold,  OPNET  Modeler,  and  OPNET  ACE  (Applieation  Capture 
Agent)  were  used  to  evaluate  individual  DSS  eomponents  at  the  IP  and  applieation  layers 
respeetively. 

The  final  area  of  testing  involved  augmented  reality.  Researeh  demonstrated  that 
AR  is  still  a  very  immature  teehnology  with  tremendous  potential  but  with  few  aetual 
implementations.  At  this  point  in  time,  it  is  not  possible  to  eall  a  single  vendor  to  order  an 
augmented  reality  suite  that  ineludes  all  the  neeessary  hardware  eomponents  and  software 
applieations.  The  AR  testing  and  evaluation  eondueted  was  based  on  a  eonsiderable 
amount  of  simulation.  The  eomputer,  display,  and  peripheral  eomponents  are  all  items 
that  might  be  used  in  a  fully  operational  AR  paekage  but  that’s  not  the  entire  story. 
Traeking  equipment  that  would  monitor  body  movements  were  not  used  and  that  is  a  big 
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piece  to  AR’S  functionality.  The  evaluations  highlighted  the  potential  and  limitations  of 
AR  technology  and  are  still  valid  to  discuss. 

A.  LOCAL  TEST  AND  EVALUATION 

The  steps  taken  during  local  testing  will  be  described  in  this  section.  The  majority 
of  testing  occurred  in  a  laboratory  environment  and  occurred  in  several  phases.  In  this, 
the  environment  was  very  controlled  and  variables  were  minimized.  Network 
connectivity  was  not  an  issue  since  both  Ethernet  and  Wireless  (802.11b)  networks  were 
stable  and  reliable. 

1,  Equipment  Used  for  Testing  and  Evaluation 

Commercially  available  computer  equipment  was  used  to  simulate  what  is  being 
used  in  the  fleet.  Two  laptop  computers  and  one  wearable  computer  were  used  as 
network  nodes.  Each  laptop  was  loaded  with  VMware  Workstation  4  since  it  allows 
additional  “virtual”  network  nodes  to  be  easily  added  while  mitigating  the  cost  of 
additional  hardware.  Virtual  machines  run  simultaneously  on  top  of  the  parent  machine 
so  the  total  number  of  nodes  equals  the  number  of  virtual  machines  plus  one.  Virtual 
Machines  are  appropriate  to  simulate  a  network  node  because  each  one  appears  as  a 
distinct  computer  to  other  network  devices.  The  number  of  VMware  virtual  machines 
running  on  a  physical  machine  is  limited  by  the  random  access  memory  (RAM)  of  the 
parent  computer  since  each  virtual  machine  receives  a  portion  of  physical  computing 
resources.  One  laptop  was  configured  with  two  virtual  machines  with  the  second  loaded 
with  1  virtual  machine.  The  wearable  computer  was  not  loaded  with  VMware  because  of 
processor  and  RAM  limitations.  There  were  a  total  of  six  nodes  used  to  simulate  a  fleet 
strike  group.  In  addition  to  the  end  nodes,  an  802.1  Ib  wireless  access  point  was  used  to 
simulate  a  satellite  for  each  node.  The  access  point  was  a  reasonable  simulation  for  a 
satellite  since  each  device  is  required  to  communicate  through  it  as  dictated  by  the 
802.1  lb  standard  under  “infrastructure  mode”  (not  ad  hoc  between  devices). 

2.  Familiarization 

This  was  started  only  after  visits  to  network  operation  centers  were  visited  and  a 
literature  review  was  conducted.  The  first  step  in  the  testing  and  evaluation  phase  was  to 
get  familiar  with  network  operations.  Specifically,  the  Solarwinds  and  Whaf  s  Up  Gold 
software  packages  were  used  to  gain  an  appreciation  for  their  features  and  capabilities. 
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Both  software  packages  offer  robust  network  operations  capabilities  but  are  very 
different  when  in  comes  to  implementation.  As  discussed  in  more  detail  in  earlier 
chapters,  the  What’s  Up  Gold  software  presents  network  information  with  graphics  as  the 
primary  view  for  devices  and  connections.  To  use  additional  functions,  users  must 
navigate  through  pull  down  menus  at  the  top  of  the  display.  Solarwinds  presents 
information  in  a  tabular  fashion  with  text-based  information.  Most  of  the  functions  for  a 
particular  tool  are  listed  in  the  primary  window  as  a  button.  An  important  consideration  is 
that  these  software  packages  are  intended  to  be  used  continuously  so  network 
performance  statistics  can  be  collected  over  time  and  trends  can  be  established.  This  is 
explicitly  presented  to  users  when  an  attempt  is  made  to  shut  down  the  software  (for 
Solarwinds,  this  depends  on  the  tool  in  use).  A  pop-up  window  is  generated  so  the  user 
must  confirm  the  shutdown  of  the  network  monitoring  software  in  both  cases.  In  this 
research,  the  software  was  run  for  various  amounts  of  time  to  allow  the  capability  to  be 
demonstrated  by  each  software  package.  An  actual  performance  history  was  not  required 
since  the  goal  was  to  determine  the  necessary  core  capabilities  for  fleet  network 
operations.  Additionally,  the  devices  used  to  create  the  test  network  were  used  for  other 
non-related  tasks  so  connectivity  was  not  maintained  continuously  between  devices. 

3,  Core  Network  Operations  Capability  Identification 

Once  an  appropriate  level  of  familiarity  with  the  network  operations  software  was 
obtained,  the  next  step  was  to  identify  those  necessary  capabilities  desired  for  network 
operations  centers.  The  purpose  here  was  to  establish  the  baseline  network  operations 
capabilities  that  would  be  used  to  monitor  fleet  information  networks.  These  functions 
are  the  core  to  the  future  fleet  network  operations  centers. 

This  was  established  using  a  combination  of  methods.  The  existing  methods  used 
by  NOCs  were  evaluated  to  determine  current  methods.  The  Pacific  Region  NOC  in 
Hawaii  was  visited  in  addition  to  the  Naval  Postgraduate  School  (NPS)  NOC.  A 
discussion  with  the  subject  matter  experts  yielded  tremendous  information  but  that  was 
only  the  first  step.  Next  the  individual  nodes  were  connected  using  both  Ethernet  and 
WLAN  architectures.  Only  information  from  the  test  laptop  and  wearable  computers  was 
collected  when  Ethernet  connectivity  was  established  on  the  NPS  network. 
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Once  the  deviees  were  connected,  the  real  eapability  discovery  began.  Initially, 
very  limited  information  was  collected  beeause  of  user  training  issues.  It  was  not  realized 
that  the  SNMP  funetionality  must  be  installed  as  an  add-in  Windows  component.  This 
hampered  the  effort  to  determine  the  functionality  of  network  management  software 
because  many  of  the  tools  required  SNMP  to  be  enabled.  Once  this  limitation  was 
overeome,  testing  of  the  speeifie  eapabilities  progressed  rapidly.  The  applieation  to  the 
fleet  environment  was  eonsidered  as  eaeh  software  tool  was  evaluated.  It  was  important 
that  the  foeus  be  maintained  beeause  of  the  unique  nature  of  the  fleet  operating 
environment. 

4,  Collaborative  Capability  Identification 

From  the  start  of  this  research,  it  was  recognized  that  collaboration  was  an 
important  aspect  to  future  fleet  network  operations.  As  stated  previously,  the  focus  was  in 
how  to  apply  these  tools  to  the  fleet.  There  are  various  collaborative  tools  suites  on  the 
commereial  market  but  the  goal  here  was  to  identify  the  core  collaborative  functions  that 
would  add  benefit  to  the  network  operations  environment.  The  suite  ehosen  was  the 
Groove  collaboration  suite  beeause  of  an  existing  relationship  with  NPS  and  beeause  it 
possesses  a  wide  variety  of  collaborative  tools  including  multiple  awareness  features.  The 
awareness  features  present  users  the  status  of  other  partieipants  whieh  is  a  enormous 
eapability  in  peer-to-peer  architeeture  where  members  may  dynamieally  enter  or  exit  a 
space  at  different  times.  This  evaluation  conducted  was  not  intended  to  validate  Groove, 
rather  it  was  intended  to  identify  the  functions  pertinent  to  the  fleet  network  operations 
environment. 

Groove  was  installed  on  the  same  computers  mentioned  earlier.  Once  loaded  onto 
each  computer,  a  collaborative  space  was  created  with  all  available  modules  included. 
From  here,  the  individual  modules  were  evaluated  for  their  potential  value  to  network 
operations.  Many  of  the  functions  covered  included  in  Groove  were  relevant  to  network 
operations.  Most  of  the  research  looked  to  see  where  communications  could  be  improved 
between  fleet  units.  Other  capabilities  (ex  file  sharing)  were  examined  for  the  ability  to 
disseminate  information  to  the  neeessary  users. 

A  signifieant  consideration  in  the  identification  of  the  collaborative  tools  was  that 

loeal  testing  did  not  validate  the  required  capabilities.  Each  was  viewed  with  the  network 
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operations  environment  in  mind,  but  only  a  theoretieal  applieation  was  determined.  The 
validation  for  the  ehosen  functions  occurred  over  the  course  of  the  STAN  experiment. 

5,  Simultaneous  Network  Management  and  Collaborative  Suite 
Operation 

The  vision  for  the  transformed  network  operations  model  includes  the  fusion  of 
collaboration  and  network  management  packages  so  there  is  one  single  application 
presented  to  users.  The  testing  for  this  in  the  laboratory  was  very  limited  as  no  human- 
system  integration  testing  was  accomplished.  The  testing  for  this  focused  on  concept 
demonstration  instead  of  a  final  implementation  perspective.  The  test  objective  was  to 
demonstrate  that  adding  collaborative  tools  would  benefit  network  management  efforts. 

This  testing  was  not  accomplished  until  after  a  familiarization  with  both 
collaborative  tools  and  network  management  was  obtained.  The  early  efforts  with  this 
research  were  directed  towards  the  network  management  software  because  the  researcher 
had  used  Groove  extensively  in  other  areas.  The  testing  commenced  once  familiar  with 
the  network  management  packages.  Preliminary  evaluation  was  conducted  in  the  lab  but 
the  true  testing  occurred  outside  the  lab  environment  during  the  STAN  experiment  (see 
next  section). 

To  accomplish  this  evaluation,  both  the  collaboration  and  network  management 
software  were  opened  at  the  same  time  on  two  different  computers.  The  primary 
computer  used  allowed  both  to  be  viewed  (100%  display  size)  because  of  a  very  high- 
resolution  screen.  The  secondary  computer  required  manual  actions  to  switch  between 
software  packages  in  order  to  see  full  views.  This  limitation  was  minor  and  did  not  affect 
the  overall  test  objective. 

The  tests  showed  that  combining  the  two  capabilities  did  provide  benefit  to 
network  operations.  Users  on  both  sides  were  able  to  effectively  communicate  about  the 
status  of  the  network.  As  problems  or  questions  arose,  it  was  very  easy  to  share  with 
other  members  of  the  group  using  a  variety  of  tools  including  chat,  voice,  and  message 
posting.  While  the  communication  capabilities  increased,  a  major  benefit  observed  was 
the  ability  of  users  in  different  locations  to  see  the  exact  same  information  (including 
content  and  presentation)  about  the  network.  Situational  awareness  software  was  enabled 

to  further  enhance  information  sharing  but  it  was  not  initially  clear  if  the  wearable 
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computer  interface  possessed  the  appropriate  eapabilities  to  provide  benefits  to  users. 
Overall  the  benefits  were  was  possible  because  the  same  network  management  packages 
were  used  during  the  testing  on  both  eomputers.  The  eommunieations  capabilities  of  the 
collaboration  software  allowed  users  to  be  see  the  same  information  displays.  In  this,  the 
time  to  explain  a  situation  is  greatly  reduced  and  users  can  focus  on  fixing  a  problem  or 
adjusting  settings  mueh  quicker. 

6.  Decision  Support  System  Capabilities  Evaluation 

Although  listed  separately,  DSS  testing  oeeurred  simultaneously  with  the 
evaluation  of  the  network  management  software.  After  condueting  a  literature  review,  it 
became  apparent  that  certain  DSS  funetions  already  resided  within  network  operations 
suites.  In  this  ease  testing  was  not  the  goal.  The  goal  of  this  research  portion  was  to 
evaluate  the  DSS  functions  already  existing  in  network  management  software  packages. 
The  result  of  the  evaluation  was  the  exposure  of  DSS  functionality  within  network 
management  software  paekages. 

7.  User  Interface 

No  testing  or  evaluation  was  conducted  in  regards  to  the  desired  user  interface  for 
the  transformed  network  operations  model. 

8.  Augmented  Reality  Testing 

The  potential  of  augmented  reality  was  evaluated  but  not  the  aetual  capabilities. 
Additional  tracking  equipment  and  specially  developed  software  are  required  for  full  AR 
testing  to  oceur.  This  researeh  sought  to  examine  the  coneept  rather  than  evaluate  a 
speeific  implementation. 

A  wearable  computer  with  a  head-mounted  display  was  used.  The  display  allowed 
the  user  to  receive  real-world  sensory  inputs  (sight,  hearing,  ete)  while  computer 
generated  information  was  projected  to  the  head-  mounted  display.  To  simulate  the  actual 
AR  software  that  would  display  augmented  network  information,  an  existing  network 
management  software  package  was  used  (Solarwinds). 

It  was  evident  that  that  AR  has  definite  promise  for  network  operations.  First,  it 
was  possible  to  monitor  network  performance  while  working  on  other  things.  This  benefit 
was  not  realized  previously  but  is  an  important  consideration.  This  means  that  man  hours 
can  be  maximized  during  times  of  acceptable  network  performance.  For  example, 
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personnel  can  work  on  training  or  qualifications  while  simultaneously  maintaining 
situational  awareness  about  network  performance.  This  is  a  huge  capability  because  it 
adds  flexibility  to  fleet  units  that  will  experience  reduced  manning  in  the  future.  Looking 
more  directly  at  the  end  AR  implementation,  it  would  be  very  beneficial  to  receive 
information  about  a  particular  device  simply  by  looking  at  it.  This  capability  exists  in 
prototype  form  (in  other  contexts)  with  the  tracking  gear  and  software  mentioned  earlier. 
This  allows  the  NOC  to  be  mobile  onboard  a  ship  instead  of  forcing  an  operator  to  remain 
in  location  for  a  given  amount  of  time.  These  capabilities  are  impressive  but  needs  to  be 
reemphasized  that  actual  testing  did  not  occur.  The  potential  benefits  of  AR  technology 
were  looked  at  but  future  research  is  required. 


B,  SURVEILLANCE  AND  TARGET  ACQUISITION  NETWORK 
EXPERIMENT 

The  Surveillance  and  Target  Acquisition  Network  (STAN)  experiment  is  a  series 
of  field  experiments  that  seeks  to  enhance  Special  Operations  Forces  (SOF).  The 
experiment  recently  completed  its  fifth  cycle  of  experimentation  with  several 
organizations  contributing  various  things  including  vendors,  contractors,  and  DOD 
entities.  The  experiment  seeks  to  accomplish  the  following  items. 

Table  8.  STAN  Objectives 

1.  Enhance  SOF  ability  to  find,  fix,  and  identify  enemy  personnel  and 
equipment 

2.  Reduce  blue-on-blue  incidents 

3.  Design,  develop  and  provide  recommendations  for  integration  of  a 
tetherless  transmit/receive  link  between  soldier,  tactical  vehicles,  ground 
sensors,  manned  and  unmanned  aircraft,  and  autonomous  underwater 
vehicles;  push-pull  of  secure  voice,  data,  and  video 

4.  Incorporate  Biometric  Software  for  identification  of  enemy  personnel 
and  equipment 

5.  Obtain  quantitative  Measures  of  Performance  for  the  STAN 

6.  Obtain  quantitative  Measures  of  Performance  for  SOF  effectiveness 
using  STAN 


In  addition  to  the  primary  objectives  listed  in  Table  8,  the  experiment  provided 
the  opportunity  to  test  concepts  for  the  transformed  network  operations  model.  A  large 
part  of  the  experiment  was  integrating  various  network  devices  and  sensors  across  a 
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variety  of  communication  paths.  The  paths  included  local  Ethernet  connections  for 
multiple  sub-networks,  long-haul  terrestrial  data  links,  and  airborne  communication  links 
using  unmanned  aerial  vehicles.  A  NOC  was  established  in  order  to  monitor  the  traffic 
throughout  the  experiment  and  served  as  the  perfect  environment  to  test  the  NOC  model 
for  the  fleet.  The  reason  this  was  able  to  replicate  the  fleet  network  is  because  it  was  a 
dynamic  network  that  would  frequently  change  as  individual  experiments  required.  It 
required  personnel  across  the  network  (end  nodes  and  NOC  personnel)  to  establish 
connectivity,  monitor  network  performance,  and  troubleshoot  problems  to  support 
experiments.  Additionally,  the  personnel  involved  were  distributed  across  several  remote 
sites  throughout  the  experiment  which  allowed  the  methods  of  communication  and 
coordination  to  be  evaluated. 

1.  Simulation  of  Current  Fleet  Network  Operations 

Although  unintentional,  the  early  attempts  to  establish  the  STAN  replicated  the 
current  methods  used  to  manage  fleet  networks.  A  network  architecture  was  established, 
devices  were  configured  with  the  appropriate  settings  (ex.,  assigned  IP  Addresses),  and 
then  the  devices  were  deployed  to  the  appropriate  locations.  Once  on  location,  the 
devices  were  powered  up  to  see  if  connectivity  could  be  established.  If  all  goes  well,  the 
devices  connect  to  the  network  and  become  visible  to  nodes  on  either  side.  Visibility  is 
determined  through  PING  functions  or  through  network  management  software.  Once  the 
network  is  established,  the  real  experiment  can  begin.  This  is  similar  to  the  way  ships  join 
the  fleet  wide  network  once  they  are  underway.  Ships  will  first  disconnect  from  the  shore 
network  and  connect  to  the  appropriate  satellite.  Once  connected  to  the  satellite,  they  can 
then  attempt  to  connect  to  the  NOC. 

Coordinating  network  problems  was  very  challenging  because  communications 
were  lacking  and  the  remote  sites  could  see  the  overall  network  picture  with  a  network 
management  software  package.  Handheld  two-way  radios  provided  the  primary 
communications  between  the  TOC  and  remote  site,  again  mirroring  the  fleet  methods. 
This  became  problematic  over  long  distances  and  users  were  forced  to  use  cellular 
phones  instead.  It  required  people  at  the  NOC  to  describe  individual  steps  for  users  to 
take  when  attempting  to  correct  network  problems.  Establishing  network  connectivity 
was  troublesome  and  it  was  very  difficult  to  coordinate  between  sites  during  this  time 
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period.  It  took  tremendous  effort  to  provide  a  physical  network  that  was  effective  enough 
to  conduct  experimentation.  Once  connected,  the  remote  sites  and  NOC  didn’t  regularly 
communicate  unless  a  problem  arose. 

2,  Evaluation  of  Improved  Network  Operations  Model 

Once  the  physical  network  could  be  established  with  regularity,  the  next  step  was 
to  use  collaboration  tools  while  conducting  network  operations.  During  the  experiment, 
Microsoft  NetMeeting  was  used  between  the  NOC  and  remote  users.  The  remote  users 
also  had  software  management  packages  installed  so  it  was  possible  to  view  the  exact 
information  without  the  NOC  having  to  describe  the  situation. 

It  is  important  to  note  that  the  network  connection  must  be  established  before 
collaboration  could  happen.  This  would  apply  to  the  fleet  as  well.  Once  connected,  the 
different  users  connected  to  the  network  could  work  together  the  status  of  the  network  as 
a  whole,  or  for  specific  devices  that  may  be  experiencing  difficulty. 

The  following  figures  are  typical  views  of  what  was  observed  during 
experimentation.  Figure  1  is  a  network  performance  summary  generated  by  Solarwinds. 
Figures  2  and  3  are  screen  captures  of  the  Situational  Awareness  application  that 


incorporated  various  collaborative  tools  and  capabilities. 
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Figure  2,  Situational  Awareness  (SA)  Picture  with  Network  Information 
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Figure  3.  Situational  Awareness  with  Video  Sharing 


For  the  STAN  experiment,  video  and  audio  were  used  between  remote  sites  and 
the  NOC  to  determine  network  status.  Users  were  easily  able  to  exchange  information 
regarding  network  performance  and  it  took  much  less  time  to  gain  situational  awareness 
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for  the  network  operations  environment.  The  AR  coneept  was  also  tested  during  the 
experiment  beeause  the  remote  site  condueting  eollaboration  and  network  monitoring  was 
a  wearable  eomputer  with  the  head-mounted  display.  Users  were  able  to  conduet  network 
monitoring,  collaborate,  in  addition  to  secondary  tasks  during  this  phase  of  the 
experiment.  This  single  series  of  experiments  served  to  validate  the  research  conducted 
for  this  paper. 
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VI.  CONCLUSION 


FORCEnet  is  intended  to  enable  Seapower  21,  the  strategic  vision  set  forth  by  the 
Chief  of  Naval  Operations,  by  integrating  the  individual  components  Sea  Strike,  Sea 
Basing,  and  Sea  Shield  with  a  combination  of  sensors,  networks,  weapons  systems,  and 
platforms.  With  this  in  mind,  the  importance  of  fleet  information  networks  grows 
tremendously.  This  concept  will  require  significant  technological  advances  to  become 
reality  but  more  importantly,  a  new  method  of  managing  information  networks  is 
required.  This  research  identifies  a  transformed  network  operations  model  for  the  fleet  in 
support  of  FORCEnet. 

A,  FINDINGS  RELATED  TO  RESEARCH  QUESTIONS 

1.  Establish  a  Collaborative  DSS  Model  That  Improves  Network 
Operations  for  Distributed  Sea  Based  Forces  Using  Existing 
Hardware  and  Software 

This  question  was  the  primary  focus  for  the  transformed  network  operations 
because  it  addresses  the  core  processes  and  functions  involved  with  fleet  network 
operations.  To  answer  this  question  the  research  sought  to  discover  the  correct 
application  of  existing  concepts  and  proven  technologies.  The  fleet  environment  was  the 
focus  throughout  the  establishment  of  the  transformed  fleet  network  operations  model.  In 
addition  to  the  fleet  perspective,  testing  and  evaluation  were  performed  to  validate  the 
concepts  identified. 

a.  Findings 

The  current  methods  and  tools  used  by  the  fleet  for  network  management 
were  considered  when  developing  an  improved  network  operations  model.  These 
observations  were  addressed  according  to  the  OSI  ECAPS  Model  to  properly  break  down 
the  key  areas  of  network  management.  Current  network  operations  are  too  centralized  for 
such  a  dynamic  operational  environment.  Three  fleet  NOCs  manage  the  networks  for 
many  ships  and  the  communication  between  ships  and  NOC  is  limited.  The  end  users  are 
not  involved  in  the  process  and  the  communication  between  the  NOC  and  fleet  assets  is 
occurs. 
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The  collaborative  DSS  model  for  network  operations  combines  network 
management  tools,  collaboration  tool  package,  and  augmented  reality  technology  to 
deliver  greatly  improved  capabilities  for  fleet  network  operations  centers.  Introduced  in 
Chapter  IV,  the  transformed  network  operations  model  is  the  fundamental  system 
architecture  that  will  support  a  dynamic  and  distributed  sea  based  force  by  providing 
ships  the  ability  to  conduct  network  operations.  It  reduces  the  complete  reliance  of  the 
fleet  from  the  three  existing  NOCs  for  network  performance  monitoring  and  allows 
increased  situational  awareness  for  the  fleet.  The  fusion  of  these  technologies  into  a 
single  system  focused  on  revolutionizes  the  war  fighter’s  ability  to  manage  information 
networks.  The  model  addresses  the  dynamic  and  distributed  nature  of  the  fleet,  provides  a 
reach  back  capability  to  vital  network  links,  and  is  based  on  commercial-off-the-shelf 
technology  to  reduce  costs  and  expedite  acquisition. 

The  transformed  network  operations  model  allows  ships  at  sea  to  manage 
vital  information  networks  as  dictated  by  the  operational  environment.  It  would  allow 
strike  groups  to  monitor  and  manage  allocated  network  resources  independently  of 
external  activities.  The  information  exchanged  between  network  managers  at  individual 
nodes  increases  user  knowledge,  thereby  increasing  the  collective  effectiveness  of  NOC 
personnel. 

2.  Incorporate  AR  Technology  for  Real-Time  Collaboration  and 
Improved  Visualization  of  Network  Performance 

This  question  addressed  a  more  radical  concept.  Augmented  Reality  is  a 
completely  new  technology  for  network  operations  since  it  has  never  been  applied 
previously.  While  there  is  not  an  existing  AR  product  for  network  operations,  it  was 
possible  to  simulate  the  concept  using  existing  hardware  and  software:  wearable 
computer  loaded  with  collaborative  and  network  management  software. 
a.  Findings 

There  are  a  couple  of  reasons  to  incorporate  AR  technology  into  the 
network  operations  domain.  The  biggest  is  the  ability  of  a  computer  to  automatically 
present  tailored  visual  information  appropriate  to  the  users  operating  environment.  The 
technology  also  demonstrated  the  ability  for  users  to  perform  additional  tasks  while 
maintaining  network  situational  awareness.  In  this  research,  the  application  of  AR 


78 


technology  to  network  operations  was  simulated  by  combining  a  wearable  computers, 
head-mounted  display,  and  network  management  software. 

The  ability  of  users  to  visualize  network  performance  was  the  key  benefit 
observed  during  research.  Even  though  the  displays  were  not  complete  AR  suites  the 
information  gathered  demonstrates  the  promise  of  the  technology.  A  second  benefit  that 
was  noted  during  the  research  is  the  flexibility  of  AR  technology.  Users  were  able  to 
manipulate  the  displays  so  they  were  customized  for  a  particular  operating  environment. 
The  flexibility  was  shown  when  users  were  switching  between  network  management  and 
situational  awareness  applications.  Users  could  easily  switch  the  display  so  it  was  tailored 
to  the  specific  situation. 

The  networking  feasibility  of  AR  equipment  is  the  next  area  for 
discussion.  The  mobile  computers  used  during  this  research  are  intended  to  be  mobile  so 
standard  Ethernet  interfaces  are  not  included.  Network  connectivity  was  established  using 
standard  wireless  local  area  network  technology  (802.11b).  While  operating  in  the  lab 
environment  and  benign  TOC  environment,  a  compact  flash  WLAN  interface  card  was 
used.  During  the  STAN  experiment  difficulties  were  experienced  when  operating  in  an 
environment  where  802.11  signals  were  amplified.  It  was  suspected  that  the  compact 
flash  WLAN  card  could  not  overcome  the  additional  noise  associated  with  the  amplified 
signals.  A  standard  WLAN  card  was  used  vice  the  compact  flash  version  and  network 
connectivity  was  achieved.  This  is  an  important  consideration  for  the  fleet  environment 
because  currently  while  it  is  physically  possible  to  network  the  devices.  Navy  policy 
prohibits  the  use  of  WLANs  in  operational  commands. 

While  the  benefits  of  the  technology  were  apparent  there  were  also  some 
problems  identified.  The  largest  problem  is  the  equipment  used  during  this  research  was 
cumbersome.  Any  AR  solution  applied  to  the  fleet  would  require  equipment  that  did  not 
have  as  many  wires  or  peripheral  devices  protruding  from  the  user.  It  was  too  easy  to  get 
caught  on  furniture  and  other  obstacles  while  wearing  the  wearable  computing 
equipment.  Considering  that  the  tracking  equipment  was  not  used,  this  is  a  significant 
hindrance  for  AR.  The  final  fleet  implementation  must  be  designed  with  better  device 
integration  in  mind  to  alleviate  this  problem. 
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The  interface  also  needs  to  be  improved  over  the  methods  used  during  this 
research.  The  hand-held  mouse  used  was  difficult  to  use  because  of  its  size  and  required 
some  adjustments  on  the  part  of  the  user.  The  method  of  data  entry  was  less  than  ideal 
because  the  wrist  worn  keyboard  used  had  only  59  keys.  This  is  significantly  less  than 
traditional  keyboards  and  while  the  buttons  were  multi-functional,  it  was  a  very  slow  and 
awkward  process  to  enter  data  into  the  computer.  The  interface  problems  are  likely 
related  to  the  level  of  technological  maturity.  AR  is  still  a  young  technology  and 
continued  development  would  probably  overcome  these  shortfalls. 


B,  FURTHER  RESEARCH 

Although  it  is  clear  that  the  transformed  network  operations  model  will  improve 
the  effectiveness  of  fleet  network  operations,  several  topics  discovered  would  reap 
significant  benefits  with  additional  research. 

1,  Technical  Aspects 

a.  Self-Forming/Self-Healing  Networks 

Research  in  ongoing  by  other  groups  about  self-forming  and  self-healing 
networks  and  this  concept  would  benefit  the  fleet  tremendously.  This  concept  would 
permit  fleet  network  nodes  to  automatically  join  and  recognize  available  networks.  The 
benefit  of  this  type  of  network  is  significant  because  it  would  alleviate  some  of  the 
requirements  to  have  a  “man  in  the  loop”  for  network  monitoring  and  management. 

Furthermore,  this  would  also  allow  network  to  automatically  identify  and 
correct  problems  including  communication  path  or  device  failures.  Other  network  devices 
or  sensors  could  recognize  a  problem  and  adjust  to  the  situation  providing  human 
decision  makers  with  consistent  information. 

b.  A  ugmented  Reality  Development 

As  stated  during  previously  in  this  paper.  Augmented  Reality  technology 
has  great  promise  for  the  network  operations  environment.  This  potential  can  be  turned 
into  a  working  product  with  additional  equipment  and  some  software  development. 

The  additional  material  required  is  commercially  available  tracking 
equipment  to  monitor  the  movements  of  the  user.  This  would  permit  the  computer  to 
recognize  what  the  user  was  looking  at  and  present  the  appropriate  information  about  a 
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network  device  or  connection.  The  software  requirement  would  provide  the  capability  for 
a  user  to  visualize  network  devices  or  connections  with  the  respective  performance.  The 
user  must  be  able  to  “drill  down”  to  increased  levels  of  granularity.  To  illustrate,  as  a  user 
is  walking  through  a  space  where  a  network  switch  is  located,  the  person  receives  a 
performance  update  simply  by  looking  at  the  device.  If  the  switch  is  shown  to  have  a 
fault,  the  user  should  be  able  to  instantly  adjust  the  computer-generated  visualization  to 
get  the  details  about  the  problem. 

c.  Identify  Specific  Network  Management  Software 

This  research  looked  at  two  network  management  software  packages  and 
specifically  avoided  recommending  one  product.  The  core  capabilities  identified  by  this 
research  for  the  network  management  function  are  a  combination  of  features  resident 
within  Solarwinds  and  Whaf  s  Up  Gold.  This  is  not  the  final  answer  to  the  transformed 
fleet  network  operations  model. 

Follow-on  research  should  identify  the  specific  software  tool  (or  tools) 
that  should  be  incorporated  into  the  fleet.  This  is  important  when  configuration 
management  is  considered  because  it  is  vital  that  each  fleet  unit  have  access  to  the  same 
information  (content  and  presentation)  to  reap  the  full  benefits  of  collaboration. 

d.  Develop  Decision  Support  System  Technology  for  Network 
Operations 

Since  self-forming/self-healing  networks  are  in  the  very  early  stages  of 
research,  the  short-term  solution  that  will  alleviate  burdens  for  NOC  personnel  are 
increased  Decision  Support  System  functionality.  More  specifically,  agents  should  be 
developed  that  can  automatically  monitor  network  performance  as  desired  by  the  decision 
maker.  This  technology  is  available  through  SNMP  or  commercially  developed  solution 
like  OPNET  Application  Characterization  Environment  (ACE)  but  would  need  to  be 
further  refined  the  fleet.  This  would  permit  users  to  have  autonomous  network 
monitoring  so  the  manual  efforts  required  by  users  would  be  reduced. 

Additional  research  within  the  DSS  domain  involves  the  user  interface. 
Human-systems  integration  subject  matter  was  not  addressed  during  this  research  because 
of  the  many  variables  involved.  This  research  evaluated  the  concept  to  joining 
collaboration  and  network  management  by  having  two  separate  applications  running 
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simultaneously  to  simulate  an  end  system.  Additional  research  should  be  aeeomplished  to 
integrate  the  eoneepts  into  a  single  manageable  solution  for  NOC  personnel. 

e.  Quantitative  Testing 

This  research  identified  concepts  and  attempted  to  validate  them  through 
demonstration  and  testing.  A  limitation  of  this  approach  was  that  quantitative  modeling 
was  not  accomplished.  Additional  research  should  look  to  quantify  the  benefits  generated 
from  incorporating  the  technologies  identified  by  this  research. 

2,  Network  Operations  Processes 

a.  Accomplishing  Network  Operations  the  Vision 

This  research  suggests  changing  the  way  the  fleet  conducts  network 
operations  but  does  not  address  how  to  accomplish  it.  Considering  there  are  varied 
stakeholders  involved  in  this  process  and  the  importance  of  fleet  information  networks, 
the  additional  research  should  identify  the  best  way  to  make  the  changes  for  the  fleet  to 
maximize  the  chances  for  success. 

Another  aspect  to  this  research  is  identifying  the  coordination  mechanisms 
that  would  be  used  to  perform  network  operations.  This  would  involve  developing  the 
procedures  that  ship  and  shore  NOCs  would  use  to  establish  decision-making  rights  and 
assign  responsibility  amongst  members  of  the  group. 

b.  Implementation  Cost  Model 

The  last  area  identified  during  this  research  involves  the  business  case  for 
transforming  fleet  network  operations.  While  this  may  not  be  a  major  acquisition 
program,  it  involves  spending  Navy  resources  on  new  systems.  Before  the  Navy  commits 
to  this,  further  research  should  identify  the  value  added  along  with  the  cost  model  so  a 
possible  return  on  investment  can  be  determined.  This  is  an  important  consideration  as 
the  DOD  moves  to  execute  its  mission  and  justify  its  expenditures. 
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